On your web site at https://100r.co/site/uxn.html it says:

MACOS. For now, the only way to get the Uxn emulator running on OS X is to build it from the source files, which means cloning or downloading the repository on Sourcehut and writing .build.sh.

First, please change both "MACOS" and "OS X" to "macOS". Apple renamed the operating system from "OS X" to "macOS" in 2016. The correct capitalization is "macOS". Please make this change everywhere else that it might appear as well.

Then, your instruction to run ".build.sh" has a typo. It should be "./build.sh".

Finally, it is untrue that the only way to get Uxn is to build from source. An alternative is to install it using MacPorts. When available, a binary provided by MacPorts will be used, and if a binary is not available, then MacPorts will build it from source. See https://ports.macports.org/port/uxn

Thanks, this works for me.

I did still see this output, even though I'm using -Dauto_features=disabled and -Dfft=vdsp and -Dresampler=libsamplerate:

Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency fftw3 found: NO (tried pkgconfig, framework and cmake)
Run-time dependency sleef found: NO (tried pkgconfig, framework and cmake)
Run-time dependency sleefdft found: NO (tried pkgconfig, framework and cmake)
Run-time dependency samplerate found: YES 0.1.9
Run-time dependency speexdsp found: NO (tried pkgconfig, framework and cmake)
Run-time dependency sndfile found: YES 1.1.0

If rubberband will definitely use my specified fft and resampler even if it finds other ones then that's fine, it's just a little surprising to see it looking for programs/libraries that I've already told it I don't want.

I also noticed the program's version number is still 3.1.0.

The failing command is:

/usr/bin/clang++ -Ilibrubberband-jni.dylib.p -I. -I../rubberband-3.1.1 -I../rubberband-3.1.1/rubberband -I../rubberband-3.1.1/src -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include/darwin -I/opt/local/include -fcolor-diagnostics -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++11 -O3 -pipe -Os -mmacosx-version-min=10.15 -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -DHAVE_VDSP -DHAVE_LIBSAMPLERATE -DLACK_SINCOS -DNO_THREAD_CHECKS -DNO_TIMING -DNDEBUG -DUSE_PTHREADS -DMALLOC_IS_ALIGNED -MD -MQ librubberband-jni.dylib.p/src_jni_RubberBandStretcherJNI.cpp.o -MF librubberband-jni.dylib.p/src_jni_RubberBandStretcherJNI.cpp.o.d -o librubberband-jni.dylib.p/src_jni_RubberBandStretcherJNI.cpp.o -c ../rubberband-3.1.1/src/jni/RubberBandStretcherJNI.cpp

So it has added -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include and -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include/darwin but these directories don't exist. /System/Library/Frameworks/JavaVM.framework/Versions/A does exist, but it doesn't contain a directory with the headers. It's normal on macOS these days for headers not to exist in system paths. They exist in the macOS SDK instead. However, this is a framework, which means headers are in a Headers directory, not an include directory.

Even if the autodetection worked, it would be good to have an option to disable it. Package managers like MacPorts want to be very specific about what dependencies a package will use. If I've programmed the MacPorts rubberband Portfile not to depend on a Java installation, I don't want to discover that on some user's system that happens to have Java installed, it does end up installing Java-related files or, worse, fail to build. In an autoconf-based package, I would be looking for a configure flag like --disable-java to ensure Java is not used even if it's present.

Sure, but all it says is:

Java compiler for the build machine: javac (unknown 11.0.16.1)
Java compiler for the host machine: javac (unknown 11.0.16.1)
Run-time dependency jni found: YES 11.0.16.1

Places where jni.h is located on my system that might be relevant:

/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jni.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jni.h
/Library/Java/JavaVirtualMachines/openjdk11/Contents/Home/include/jni.h
/opt/local/include/libavcodec/jni.h

rubberband 3.1.1 fails to build for me on macOS 10.15.7:

../rubberband-3.1.1/src/jni/RubberBandStretcherJNI.cpp:28:10: fatal error: 'jni.h' file not found
#include <jni.h>
         ^~~~~~~
1 error generated.

Earlier meson said:

Java compiler for the host machine: javac (unknown 11.0.16.1)
Run-time dependency jni found: YES 11.0.16.1
meson.build:147: WARNING: Project targets '>= 0.53.0' but uses feature introduced in '0.62.0': dep 'jni' custom lookup.

  Build targets

    JNI library              : YES
                               Name: rubberband-jni

I have meson 0.63.3 installed.

If I edit meson.build to change 0.53.0 to 0.62.0 that removes the warning but does not fix the build.

I don't want anything related to Java, but I don't know what the meson equivalent of ./configure --help is so I don't know how to discover whether your build system offers a way to disable this feature.