Thanks! I've made another change as well, since (even with the ability to switch off JNI manually) I was most unhappy with the autodetection failing in what looks like a pretty normal situation.
The new change is just that it doesn't take Meson's word for it when it reports having found the JNI dependency - it checks for Java, then checks for JNI using the built-in logic, then also checks that the compiler can find
jni.hand only goes ahead if that is true. So this should mean that a build without any feature overrides should do the right thing for you as well, now. I'd appreciate any feedback on this, since most of the changes in this area I've made so far have turned out to have unintended consequences!
Couple of other notes:
WARNING: Project targets '>= 0.53.0' but uses feature introduced in '0.62.0': dep 'jni' custom lookup.- This is essentially because the meaning of the existing dependency lookup syntax changed in 0.62, so as to introduce a special case for
jni. Before that,
jniwas just looked up using
pkg-configin the normal way. Either of these is fine as far as it goes, since this is supposed to be an optional dependency anyway - so 0.62 is not actually needed despite the message, and since I still use CI environments with older versions of Meson, I don't want to require it.
"If rubberband will definitely use my specified fft and resampler even if it finds other ones" - it looks as if it hasn't found other ones... it has found only
libsamplerate, which is the one you wanted, and I can't tell for sure whether this is because the other libraries are not present or because it has short-circuited the checks to fail because the libraries were disabled on request. The message suggests the former but I wouldn't be certain! The build file is definitely written in such a way as to probe the libraries available before making a decision about which ones to use. The effect of
auto_features=disabledis, I believe, to act as if the probes fail rather than to alter the decision that is made. It is slightly too magical for my liking so I would certainly be curious about any situation in which it actually produces the wrong result.
Hm, yes that is quite poor isn't it.
I found the official Meson mechanism for enabling and disabling features, and have pushed a change to add support for it. You should be able to run
meson build -Djni=disabled
to configure without JNI support. Also you can disable all optional features and then re-enable them individually, which sounds like what you might want if you're trying to be careful about dependencies. For example:
$ meson build -Dauto_features=disabled -Dcmdline=enabled -Dladspa=enabled -Dlv2=enabled
That might be a bit too laborious though, and it has the potential disadvantage that you might never even notice if a new optional target is added.
I'd be grateful if you can try this out and report how you get on!
If you run
ninja -v, it should print the commands run in the build, presumably ending with the one that fails. What is the full compiler command-line for that? I'd like to see whether Meson has decided to add some Java-related path to it, and if so, what that is.
Oh no, not again! It was an inconsistency in the Java/JNI lookup that prompted the 3.1.1 release in the first place - it was breaking builds for people who (like most of us) had no need of the JNI support. I really thought the fix in 3.1.1 should have solved it, and I was foolishly confident enough that I didn't add an explicit flag to disable it at the same time, as I should have.
I'm very curious about how and where Meson thinks it has found the JNI dependency, given that it then fails to find the header. Can you paste in the lines from
build/meson-logs/meson-log.txtthat deal with looking up
jni.h, please? Should be a couple of dozen lines starting with the first reference to
Thank you! It's in the 3.1.1 release now.
Thanks for this, and for the added info at https://github.com/breakfastquay/rubberband/issues/73#issuecomment-1275612223 - I will give this a try and see how it fares in the CI environments.
Closing this one, as I can't currently think of any obvious improvement even though the current solution is still not totally ideal. It will do, I hope.
Major overhaul of variable-rate pitch shifting arrived in v2. Closing