Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wscript] Please add a --netjack option #33

Closed
karllinden opened this issue May 10, 2013 · 2 comments
Closed

[wscript] Please add a --netjack option #33

karllinden opened this issue May 10, 2013 · 2 comments

Comments

@karllinden
Copy link
Contributor

Hi!

It would be great if there was a --netjack option for waf. I suggest the following behaviour:

  • Build netjack if and only if --netjack is given
  • Print an error if it cannot be built and it was requested

The reason for such a change is that in Gentoo (where sources are built by the package manager) dependencies will break and the user will not get what he/she requested (i.e no netjack) if netjack is auto-detected as it is now.

The following situation might occur:

  1. The user installs the opus library (maybe another package than jack pulled it in)
  2. The user installs jack and requests it to not build netjack (i.e. the opus use flag i unset), but the build system finds opus, builds and install netjack
  3. The user uninstalls opus library for some reason
    In this situation the user is unaware that the package jack now contains broken link-level dependencies and he/she will have to recompile jack to get rid of them.

The initial suggestion above solves this issue by not using auto-detection if netjack is not requested.

Thanks in advance,
Karl

@x42
Copy link
Member

x42 commented May 14, 2013

This seems like a gentoo (and similiar distro) specific packaging problem.

--enable-nejack, --disable-netjackwould only be a workaround for such situations, not a solution.
There are a lot of very similar issues and jack won't get an option for all of those. This needs to be fixed by the distributor.

e.g. Step (3) s/libopus/libc/ -- what if the user uninstalls libc for some reason? or less dramatic: The user removes libsndfile? You are suggesting that jack should have an option for all its dependencies and and have them set to disabled by default?

Any sane GNU/Linux distribution will not allow Step (3) without warning the user or explicitly requiring confirmation.
This problem cannot be fixed by jack.

@x42 x42 closed this as completed May 14, 2013
@karllinden
Copy link
Contributor Author

No, I didn't mean all dependencies should be disabled by default. That is completely different. Libc and libsndfile are mandatory to build, libopus is not. Furthermore, the user is on his/her own if he/she decides to remove libc or libsndfile. (The package manager will complain, eventually). The case with libopus is different in the sense that the build system might decide to build against libopus event if the user thinks it doesn't. On the contrary, the user will always know jack builds against libsndfile and libc; the build system cannot spontaneously decide whether or not to use libc.

I have no problems with libopus being detected and built against if the user does not make a choice to turn it off. However, if the user has libopus and does not want jack to be built with netjack then he/she has to remove libopus (or at least make sure waf doesn't find the headers) in order to build properly. It currently is that way. It is not very convenient nor does it respect the user's right to choose. (There are not a lot of packages that require libopus, hence it will not likely be installed on a system without jack requiring it, but such a situation might arise).

We (the maintainers) can of course add some kind of hack so that it would seem like opus is not accessible on the system, but a solution upstream would be superior to such a hack. We could also hard-enable it, but that just does not make any sense - everyone does not want netjack.

It would be a solution. We would get rid of the problems arising from the package manager not knowing what libraries the program built against because of a refractory build system.

If you would rather choose a --no-netjack option that would be fine. As long as the dependency can be controlled in some way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants