Comment by ~eschwartz on ~lattis/muon
Well, uname is a program for reporting the running kernel information. Containers are really no different from installing an i386 package on an x86_64 OS, and only running that i386 package -- files you're not using really don't matter, whether you choose to not use them or a sandbox forbids you from using them.
~eschwartz is referring to https://todo.sr.ht/~lattis/muon/76, which could be the issue here, I'm not sure. 0.1.0 did pass all tests on all architectures alpine supports, so it seems likely that this is a case of muon reporting wrong system information.
Il giorno dom 22 gen 2023 alle 18:18:10 +00:00:00, ~eschwartz outgoing@sr.ht ha scritto:
the platform detection code uses uname instead of the compiler defines, which triggers some interesting issues for multilib?
What do you mean with multilib? As far as I can tell, that CI runner uses only i386 packages (compiler, libs, etc). But maybe the underlying kernel of the container's host is amd64, so that's what could be causing the issue?
-- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
Comment by ~eschwartz on ~lattis/muon
I have some vague memory that the platform detection code uses uname instead of the compiler defines, which triggers some interesting issues for multilib?
Comment by ~eschwartz on ~breakfastquay/rubberband
Awesome, happy to help.
(Late response due to holiday stuff going on.)
Ticket created by ~eschwartz on ~breakfastquay/rubberband
See the following two-part patch, which tries to add java to the languages, and then uses Meson's builtin jar handler.
# HG changeset patch # User Eli Schwartz <eschwartz93@gmail.com> # Date 1665102481 14400 # Thu Oct 06 20:28:01 2022 -0400 # Node ID e00fac5dbb764dc4fe533b444beb2932d30ad4b4 # Parent 16302890e6b1c51498a98c82f03270cf6c579e2b meson: use builtin add_languages to detect if jni is findable diff -r 16302890e6b1 -r e00fac5dbb76 meson.build --- a/meson.build Fri Sep 30 14:53:53 2022 +0100 +++ b/meson.build Thu Oct 06 20:28:01 2022 -0400 @@ -128,14 +128,12 @@ prefix: '#define _GNU_SOURCE\n#include <math.h>', args: '-lm') -javac = find_program('javac', required: false) -jar = find_program('jar', required: false) - -# Look for JNI only if javac and jar are found. This is because the +have_java = add_languages('java', required: false) +# Look for JNI only if javac language is found. This is because the # auto-JNI-dependency module in Meson 0.62 and 0.63 appears to bail # out of the build completely if it can't find javac, even when # required is false -if javac.found() and jar.found() +if have_java 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) @@ -144,8 +142,8 @@ 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() + # used below because we are conditional on it being found + jni_dep = dependency('', required: false) endif @@ -507,7 +505,7 @@ # if get_option('default_library') != 'shared' rubberband_additional_static_lib = 'rubberband-static' - endif + endif rubberband_library_name = 'rubberband' rubberband_program_name = 'rubberband-program' rubberband_program_name_r3 = 'rubberband-program-r3' @@ -567,7 +565,7 @@ message('Will build Rubber Band Library dynamic library') target_summary += { 'Dynamic library': [ true, 'Name: ' + rubberband_library_name ] } endif - + rubberband_library = library( rubberband_library_name, # We would like to write "link_with: rubberband_objlib", @@ -601,7 +599,7 @@ ) endif -if jni_dep.found() and javac.found() and jar.found() +if jni_dep.found() target_summary += { 'JNI library': [ true, 'Name: ' + rubberband_jni_name ] } message('Will build Java Native Interface') rubberband_jni = shared_library( @@ -622,12 +620,14 @@ # NB the JNI library is not versioned install: true, ) + javac = find_program('javac') rubberband_class = custom_target( 'rubberband_class', input: 'com/breakfastquay/rubberband/RubberBandStretcher.java', output: 'RubberBandStretcher.class', command: [ javac, '@INPUT@', '-d', '@OUTDIR@' ], ) + jar = find_program('jar') rubberband_jar = custom_target( 'rubberband_jar', input: rubberband_class, @@ -637,7 +637,7 @@ ) else target_summary += { 'JNI library': false } - if not (javac.found() and jar.found()) + if not have_java message('Not building Java Native Interface: Java compiler or archiver missing') else message('Not building Java Native Interface: JNI header not found') # HG changeset patch # User Eli Schwartz <eschwartz93@gmail.com> # Date 1665102569 14400 # Thu Oct 06 20:29:29 2022 -0400 # Node ID 7b4f49a01fc7b8c3bbe3d203e16bb5f5634d0c7e # Parent e00fac5dbb764dc4fe533b444beb2932d30ad4b4 meson: use builtin jar function to compile jar file It's simpler, and handles rebuild outputs for the class automatically. diff -r e00fac5dbb76 -r 7b4f49a01fc7 meson.build --- a/meson.build Thu Oct 06 20:28:01 2022 -0400 +++ b/meson.build Thu Oct 06 20:29:29 2022 -0400 @@ -620,21 +620,7 @@ # NB the JNI library is not versioned install: true, ) - javac = find_program('javac') - rubberband_class = custom_target( - 'rubberband_class', - input: 'com/breakfastquay/rubberband/RubberBandStretcher.java', - output: 'RubberBandStretcher.class', - command: [ javac, '@INPUT@', '-d', '@OUTDIR@' ], - ) - jar = find_program('jar') - rubberband_jar = custom_target( - 'rubberband_jar', - input: rubberband_class, - output: 'rubberband.jar', - command: [ jar, 'cvf', '@OUTPUT@', 'com/breakfastquay/rubberband/@INPUT@' ], - build_by_default: true, - ) + jar('rubberband', 'com/breakfastquay/rubberband/RubberBandStretcher.java') else target_summary += { 'JNI library': false } if not have_java
Comment by ~eschwartz on ~lattis/muon
samu also uses Make to build, which is also highly portable including older platforms.
Comment by ~eschwartz on ~lattis/muon
Please note that access to this system is restricted to current Arca Noae support subscribers. If your subscription has expired, your account here will be disabled and you will need to renew or purchase a new support subscription to regain access.
I'll take your word for it. :D
Comment by ~eschwartz on ~lattis/muon
Muon does not support custom (non-pkgconfig) dependencies for the most part. IIRC there's a framework stub for it and one or two (threads?) is actually implemented...
Comment by ~eschwartz on ~lattis/muon
This has been discussed in the past, for example at https://lists.sr.ht/~lattis/muon/%3CwPjhrtnauq3W6yQoMO8fxIzXjnU5BJkZl9cMW9apk_qlIneI-T9R3KGF1kmEps0B9UKKr6Frn4FN4M_gw-70we6NtbbV73Yh5_HF-A5Magc%3D%40protonmail.com%3E#%3C20211031032719.ysf4isb6rvefvequ@hostomei%3E
It may very well be time to finally create a stable release.