I found a problem while building a lib for slackware x86_64, when installing the resulting .pc file is "defective"
# muon setup -Dprefix=/usr -Dlibdir=/usr/lib64 builddir
# muon -C builddir install
/usr/lib64/pkgconfig/jsoncpp.pc
prefix=/usr
includedir=${prefix}/include
libdir=${prefix}//usr/lib64
Name: jsoncpp
Version: 1.9.4
Libs: -L${libdir} -ljsoncpp
Cflags: -I${includedir}
# meson setup -Dprefix=/usr -Dlibdir=/usr/lib64 builddir
# meson install -C builddir
/usr/lib64/pkgconfig/jsoncpp.pc
prefix=/usr
includedir=${prefix}/include
libdir=${prefix}/lib64
Name: jsoncpp
Version: 1.9.4
Libs: -L${libdir} -ljsoncpp
Cflags: -I${includedir}
-Dlibdir=/usr/lib64 overrides the whole libdir including the prefix, so at the very least:
this:
libdir=${prefix}//usr/lib64
should be
libdir=/usr/lib64 (don't prepend ${prefix}/)
Meson apparently evaluates each dir and replaces strings.
In this case, it removed the prefix (/usr) from libdir and prepended ${prefix}
libdir=${prefix}/lib64
The Meson approach is not really needed, since it's basically the same logic with extra post-processing
I suspect this affects any special variable that is overridden by -Dxxxx=, so basically muon should NOT prepend ${prefix} to special variables that have been overridden...
Meson apparently evaluates each dir and replaces strings.
Setting
meson setup -Dprefix=/usr -Dlibdir=/usr/lib64will determine that libdir is a subdirectory of prefix and trim this during option processing.The value of
get_option('libdir')is'lib64', so, much later on, when meson.build is evaluated and the pkgconfig module is imported and used, it just sees that.
So it appears the problem is that muon is not smart enough to clean up your options for you. Does everything work if you specify libdir relative to prefix e.g. -Dlibdir=lib64?
With
-Dlibdir=lib64I get the correct behavior. Identical files. muon = mesonThis behavior is too smart, it's different from cmake and autotools
In autotools, if you override a path, you'll clearly see it
prefix=/usr exec_prefix=${prefix} libdir=/usr/lib64 includedir=${prefix}/includeIn cmake it's a mess, if you want to override libdir name, it's
-DCMAKE_INSTALL_LIBDIR=lib64(-Dlibdir=lib64)But if you want to override the full libdir it's
-DCMAKE_INSTALL_FULL_LIBDIR=/usr/lib64(-Dlibdir=/usr/lib64)This discrepancy should be fixed, muon should be smarter... -Dlibdir=/usr/lib64 shouldn't produce a broken path
Actually in autotools you need to single-quote and pass arguments like this:
./configure --prefix=/usr --libdir='${prefix}/lib64' --includedir='${prefix}/include'That then gets eval'ed as shell code in some contexts, and replaced as-is in Makefile.in or other *.in files (such as libfoo.pc.in). And pkg-config files are (intentionally, IIRC) compatible with the limited subset of shell code that is commonly used for passing two-pass "delayed evaluation" directory options to autoconf.
I believe a new tagged release should be created after this issue is fixed (to satisfy distros)
muon 0.1.0 is way too broken and I thought the project was still in alpha phase, until I decided to compile the latest muon revision
Currently muon can be used in very complex ways with proper (exported) CFLAGS / LDFLAGS / CC , etc... even though it still can't handle several projects properly (have to use meson instead), it's quite good
It officially doesn't support cross compiling, but I use muon to cross compile with the same env variables I pass to autotools
So this is the most obvious issue I found so far
This should be fixed in 6c0547b470086af5cd26dd76920fdbf56abb91b2