Hi, Looking at poppler 0.60.1, I saw that it removes the autotools build system, and it looks like the cmake build system hardcodes libdir to ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX} Unfortunately that's not good in all situations. E.g. in Debian we have multiarch directories, so libraries go in /usr/lib/<triplet>/. I could do that with autotools by setting --libdir (which our tooling does automatically) but I can't do it anymore in the cmake build system. I hear there's a GNUInstallDirs cmake thing that sets some stuff, e.g. CMAKE_INSTALL_LIBDIR. Would it be possible to use that so that the libdir can be controlled? https://cmake.org/cmake/help/v3.3/module/GNUInstallDirs.html
Created attachment 134892 [details] [review] cmake: support GNUInstallDirs
That patch seems ok to me, does it solve your issues?
It does. With it I can build with -DCMAKE_INSTALL_LIBDIR="path/to/lib/dir" and things go to the appropriate place.
Pushed
Unfortunately this has the side-effect of breaking the pkg-config files for everyone else who isn't explicitly setting CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_INCLUDEDIR. The reason is that rather than ending up with libdir=${exec_prefix}/lib includedir=${prefix}/include instead, by default, you get libdir=lib includedir=include I expect 0.61.0 will be a bit of a mess from a downstream packaging perspective as a result. In Homebrew, while working on the 0.61.0 upgrade pull request, I just had to puzzle around over why none of the reverse dependencies would build until I found that the pkg-config files were broken and traced it back here. Multiply that by every other downstream and you get the picture.
bug 103578
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.