support GNUInstallDirs in CmakeLists.txt?

[sten0]

Hi @Martchus,

I had to implement a workaround for the absence of GNUInstallDirs support. How do you feel about adding support for this, for non-Darwin unix-like systems? This also applies to qtutilities and Syncthing Tray, and IIRC it will make maintaining the Plasma integration easier and less error-prone, because IIRC various distro-level Debian build helpers require it. Asking to support it is also something we're supposed to ask for (in Debian), so there's also that ;-)

Best,
Nicholas

[Martchus]

I need to check what GNUInstallDirs actually does. Note that the current installation "layout" and its options for configuration was so far sufficient to package for different distributions, e.g. Arch Linux and openSUSE. I'm wondering what special requirements you have?

[Martchus]

I've been remembering that module again. When I've came across the module the first time it wasn't working like I'd expect as an Arch Linux user so I didn't consider using it.

This has now been fixed. The lib64 default for 64-bit looks still a little bit odd to me and making now suddenly use of it would break existing build scripts for my project. So I guess I'll use that module but still keep lib as default. Distributions which use something else can set CMAKE_INSTALL_LIBDIR. Note that you can already set the custom variables LIB_SUFFIX, LIB_SUFFIX_32 and LIB_SUFFIX_64.

[sten0]

Martchus <notifications@github.com> writes:

I've been remembering that module again. When I've came across the module the first time it wasn't working like I'd expect as an Arch Linux user so I didn't consider using it.

Out of curiousity, does Arch support multiarch and/or cross-compilation, and if so, does it use a different method?

This [has now been fixed](Kitware/CMake@1836558#diff-ddd40a000ca37e13b4cae5b9bd023c53).

Thank you, much appreciated :-)

The `lib64` default for 64-bit looks still a little bit odd to me and making now suddenly use of it would break existing build scripts for my project. So I guess I'll use that module but still keep `lib` as default.

Thanks that makes sense, and I agree. I wonder if `lib64` is a RedHat or SUSE convention? What I've seen on all Debian-like systems is this: $PREFIX/lib is the native arch (amd64/x86_64 for most), and then 32bit stuff goes in $PREFIX/lib32, $PREFIX/libx32, and $PREFIX/i686-linux-gnu, where $PREFIX is generally /usr, and where i686-linux-gnu seems to exclusively be used for a minimal subset of glibc and/or possibly gcc runtime libs.

Distributions which use something else can set `CMAKE_INSTALL_LIBDIR`. Note that you can already set the custom variables `LIB_SUFFIX`, `LIB_SUFFIX_32` and `LIB_SUFFIX_64`.

Ah, yes, those are a few of the variables that our CMake helper sets; although, I suspect it also adds hooks to the bin:pkg for the package manager (dpkg), to install non-native binaries to the correct location (at installation time), possibly with some magic dust...Arch, CRUX, and Slackware's packaging and package managers are much easier to understand! Cheers, Nicholas

[sten0]

Martchus <notifications@github.com> writes:

I need to check what `GNUInstallDirs` actually does. Note that the current installation "layout" and its options for configuration was so far sufficient to package for different distributions, e.g. Arch Linux and openSUSE. I'm wondering what special requirements you have?

Debian uses it to support multiarch (the common 32bit on 64bit, eg: Wine32 plus supporting 32bit libs) and cross-compilation; IIRC some people are also using multiarch with binfmt_misc and qemu to emulate foreign archs, but I could be wrong about this...it's well outside the areas I work on. P.S. If this subject is something you're interested in, Helmut Grohne is the guy to talk to. If he ends up using Syncthing Tray and if there are any future issues he'll almost certainly submit clean and well-formatted patches :-) There's an incomplete document for maintainers here: https://wiki.debian.org/Multiarch/Implementation#CMake As for the "why am I asking for this", `GNUInstallDirs` is desired by people working in the areas that I'm not, and if it's a political thing, then the politics would be along the lines of "Debian: The Universal OS", which has multi/foreign arch for legacy support, boostrapping new archs, and as a workstation for embedded and Android development. My best answer for "how does this relate to a plasmoid for desktop users" is that supporting others' efforts is a community solidarity thing even for people in different subsets of that community. Best, Nicholas

[Martchus]

Out of curiousity, does Arch support multiarch and/or cross-compilation,
and if so, does it use a different method?

32-bit libraries for use on a 64-bit system are provided by Arch and go under lib32. Cross compilation packages provided by the Arch community install the libraries built for the target architecture within a completely different prefix. There's also a good reason to do that when cross compiling:

Note that include dir does not contain the triplet part. This may cause problems if your library has arch-specific header files.

(Quote from the Debian Wiki page you've mentioned.)

Not sure who uses lib64 but judging by the implementation of GNUInstallDirs it is less specific than the Debian case.

[Martchus]

This is implemented now. Let me know if something is missing.

[kapsh]

@Martchus Hi! It seems to me that you've missed a couple of places in AppTarget.cmake. Variables DESKTOP_FILES, ICON_FILES are still using literal share. Mind checking that please?

[Martchus]

I've fixed the hopefully last remaining hard-coded paths.

[kapsh]

Thanks! Everything is in order now.

A little explanation: without that tageditor's icon wound up in /usr/x86_64-pc-linux-gnu/share/icons/hicolor/scalable/apps/tageditor.svg on Exherbo Linux. In this distribution CMAKE_INSTALL_PREFIX is usually set to /usr/<triplet> and used for architecture dependent files (binaries usually). Platform independent parts (icons, docs, etc.) are supposed to use CMAKE_INSTALL_DATAROOTDIR.