Building with meson yields "Unknown Compiler: javac" after it finds javac

[langermarc19]

I am trying to compile rubberband using meson.

I get the following error:

coming from these lines in the meson.build:

if javac.found() and jar.found()
  jni_dep = dependency('jni', version: '>= 7.0.0', required: false)
  if not jni_dep.found()
    if cpp.has_header('jni.h', args: extra_include_args)
      jni_dep = declare_dependency()
    endif
  endif
else
  # Declare jni_dep so it isn't totally undefined - but it won't be
  # used below because we are conditional on javac/jar as well
  jni_dep = declare_dependency()
endif

I don't understand why if it's finding jar and javac it's then giving the unknown compiler error.

[daschuer]

I suffer the same issue here: https://github.com/microsoft/vcpkg/pull/27114

I am not interested in the Java interface in that case. Is there a workaround to skip that check without patching the Rubberband source?

[cannam]

I didn't understand this either, until I saw the notes in the bug filed to Meson (https://github.com/mesonbuild/meson/issues/10900)

So there is a javac program installed, but it is not a compiler, it's just a program that tells you to install a compiler. That's a situation I really wouldn't have thought of - and that seems almost unfair to be asked to deal with, but I guess it's reality!

There is another proposal (https://todo.sr.ht/~breakfastquay/rubberband/25) to switch to specifying Java as an additional optional project language and letting Meson sort it out, rather than looking up the tools one by one. I don't know whether that would fare any better.

Perhaps not, because this failure actually occurs in magic Meson logic, not in my own scripted logic. Meson is taking control when I request the jni dependency (line 139) and checking that the Java compiler works, which is something I don't explicitly ask it to do at that point - if a system lacks a working Java compiler it almost certainly also lacks jni.h which means my lookup would happily fail and continue without, if Meson wasn't getting clever.

I can't think of any workaround that doesn't involve modifying meson.build, other than to ensure that javac is genuinely not in the path. (Or to install Java but I get why you don't want to do that.)

Given how fragile this has turned out, it was undoubtedly a mistake to make building the JNI interface automatic - it should have been left opt-in as very few people use it. Unfortunately, when it was opt-in, it was so little exercised that it actually didn't build at all in the 3.0.0 release, which is the main reason I made it automatic in the first place - so that my own builds and CI exercises would pick it up where possible. But I can always script that as an additional build test instead.

[eli-schwartz]

There is another proposal (https://todo.sr.ht/~breakfastquay/rubberband/25) to switch to specifying Java as an additional optional project language and letting Meson sort it out, rather than looking up the tools one by one. I don't know whether that would fare any better.

I submitted that patch after testing that it succeeded at configuring, when my mocking stub for javac (that successfully returns without reporting sensible information as a compiler, but is found as a "program") had failed with the mentioned error.

Basically what happens is that the jni dependency requires you have java as a project language, and somewhat unusually, it goes ahead and adds it for you if you don't have it already. This is very possibly a bug...

... and then it does so in required mode, even if the jni dependency was optional. This is unquestionably a Meson bug.

But, attempting to add_languages() yourself and using that to see if it's worth checking for the jni dependency should be robust, since if it succeeds then dependency('jni') will not attempt to look for a java compiler on its own.

[cannam]

I pushed the fix from Eli (a week ago) and it seems to have been happily accepted by CI environments and the like. If anyone would like to test it before it gets tagged for a new release, now's the time! Otherwise I'll put out a minor release, perhaps tomorrow, with only this fix in it.

Thanks!

[cannam]

Right-o, it's out as 3.1.1. Thanks everyone!