~lattis/muon#90: Problem with generated pkg-config (.pc) files - libdir

I found a problem while building a lib for slackware x86_64, when installing the resulting .pc file is "defective"

#muon fb2ecd9

# 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 1.0.1

# 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}

#details

-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...

Status: RESOLVED FIXED
Submitter: ~wdlkmpx
Assigned to: No-one
Submitted: 8 months ago
Updated: 8 months ago
Labels: No labels applied.

~eschwartz 8 months ago

Meson apparently evaluates each dir and replaces strings.

Setting meson setup -Dprefix=/usr -Dlibdir=/usr/lib64 will 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.

~lattis 8 months ago

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?

~wdlkmpx 8 months ago

With -Dlibdir=lib64 I get the correct behavior. Identical files. muon = meson

This 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}/include
In 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

~eschwartz 8 months ago*

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.

~wdlkmpx 8 months ago

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

~lattis REPORTED FIXED 8 months ago

This should be fixed in 6c0547b470086af5cd26dd76920fdbf56abb91b2