#26 fatal error: 'jni.h' file not found a month ago

Comment by ~cannam on ~breakfastquay/rubberband

REPORTED RESOLVED CLOSED

#26 fatal error: 'jni.h' file not found 2 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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.h and 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, jni was just looked up using pkg-config in 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=disabled is, 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.

#26 fatal error: 'jni.h' file not found 2 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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!

#26 fatal error: 'jni.h' file not found 3 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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.

#26 fatal error: 'jni.h' file not found 3 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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.txt that deal with looking up jni.h, please? Should be a couple of dozen lines starting with the first reference to javac or jni.

#25 java jar handling could use builtin meson functions 3 months ago

Comment by ~cannam on ~breakfastquay/rubberband

Thank you! It's in the 3.1.1 release now.

REPORTED RESOLVED CLOSED

#25 java jar handling could use builtin meson functions 3 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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.

#20 output file extension is ignored 4 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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.

REPORTED RESOLVED CLOSED

#11 Modulation when changing pitch of pure sine tone 4 months ago

Comment by ~cannam on ~breakfastquay/rubberband

Major overhaul of variable-rate pitch shifting arrived in v2. Closing

REPORTED RESOLVED CLOSED

#18 Assertion in MovingMedian::drop 4 months ago

Comment by ~cannam on ~breakfastquay/rubberband

REPORTED RESOLVED CLOSED