CMake: make installation directories more configurable

[hasufell]

We use GNUInstallDirs now to be able to control the following variables: CMAKE_INSTALL_LIBDIR CMAKE_INSTALL_INCLUDEDIR

In case cmake version is less than 3.0.0, we just provide these variables manually and match the previous default.

This fixes support for distribution that have a multi-arch setup. Also see https://github.com/gentoo/gentoo/pull/22

[andrewrk]

Thanks, glad we came to something that works for all parties.

[andrewrk]

@hasufell looks like CMAKE_INSTALL_LIBDIR is not adequate for debian; it needs CMAKE_INSTALL_FULL_LIBDIR.

See:

• http://www.cmake.org/cmake/help/v3.1/module/GNUInstallDirs.html
• https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/tree/debian/patches/Enable-multiarch.patch?id=a4be256b30625db8829a5d752dc71aa4eb61229b

Is CMAKE_INSTALL_FULL_* et all compatible with Gentoo's packaging?

[hasufell]

looks like CMAKE_INSTALL_LIBDIR is not adequate for debian; it needs CMAKE_INSTALL_FULL_LIBDIR

For install rules CMAKE_INSTALL_PREFIX is automatically prepended to non-absolute paths (like CMAKE_INSTALL_LIBDIR can be). It is very common to set these variables to non-absolute paths, so you can control the prefix for all of them at once. CMAKE_INSTALL_FULL_LIBDIR does the same (but on variable level) and is not meant to be set manually, see GNUInstallDirs.cmake:

  if(NOT IS_ABSOLUTE ${CMAKE_INSTALL_${dir}})
    set(CMAKE_INSTALL_FULL_${dir} "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_${dir}}")
  else()
    set(CMAKE_INSTALL_FULL_${dir} "${CMAKE_INSTALL_${dir}}")
  endif()

tldr: it makes zero difference in our case. If it does, then debian is doing something wrong.

[andrewrk]

I discovered that CMAKE_INSTALL_LIBDIR is fine on Debian. I was mislead by a mail from debian-devel. The problem was in my CMakeLists.txt and fixed by this patch: https://github.com/andrewrk/libsoundio/commit/673e28aa770ef2e18a5e4555a7a3c1c2293d54d7

(I haven't committed the patch to libgroove yet; I have some in progress stuff in my working tree)

[andrewrk]

Comment on the Arch linux package for libsoundio: https://aur.archlinux.org/packages/libsoundio-git/

I removed /usr/lib64 (which was a symlink to /usr/lib and owned by the filesystem package), and continued. libsoundio-git then created /usr/lib64 as a normal directory, which results in everything under /usr/lib no longer being on the PATH. I looked in the pkgconfig, but couldn't see any references to /usr/lib64, so I think it may be a problem with libsoundio's build system.

I wonder if this is GNUInstallDirs causing this. I want to do the right thing as the upstream developer but I'm starting to think that I should just leave things simple and leave it to package maintainers to patch their way around the build script.

[hasufell]

I don't understand the problem. The path is configurable. It's not an improvement if people have to patch it downstream. They are probably just missing -DCMAKE_INSTALL_LIBDIR=lib.

To put it diplomatic... AUR packages are known to have low quality and contain dirty hacks. Even CMAKE_INSTALL_PREFIX is not set correctly in that PKGBUILD.

[andrewrk]

OK thanks good to know. I'll leave it as is then.