Incorrect CMAKE_INSTALL_LIBDIR with 3.23rc3 on Debian? Is this a bug?

Usage
1

With the CMake 3.23 release candidates, the CMAKE_INSTALL_LIBDIR result variable provided by GnuInstallDirs contains the architecture name even when installing to a private location. Is this a bug or an intentional change?

Specifically, instead of lib or lib64, I am getting lib/x86_64-linux-gnu.

The documentation states that:

LIBDIR

object code libraries (lib or lib64)

On Debian, this may be lib/<multiarch-tuple> when CMAKE_INSTALL_PREFIX is /, /usr, or /usr/local.

However, I set CMAKE_INSTALL_PREFIX to a private location, not one of the three systems locations mentioned here. Therefore, I expect to get simply lib and not lib/x86_64-linux-gnu.

Indeed, with version 3.20 I get lib, but with 3.23rc3 I get lib/x86_64-linux-gnu.

Is this a bug?

Note that this change is causing python-igraph to fail to compile on Debian, and we need to decide whether to work around it or wait for a fix: memory leak about creating igraph in for loop · Issue #517 · igraph/python-igraph · GitHub

2

This was probably from this MR. Given the docs, a custom CMAKE_INSTALL_PREFIX getting this change seems unintentional to me.

Cc: @malaterre @brad.king

3

I just configured the following CMakeLists.txt with -DCMAKE_INSTALL_PREFIX=/home/kyle/.local:

cmake_minimum_required(VERSION 3.23)
project(test C)

include(GNUInstallDirs)

and got CMAKE_INSTALL_LIBDIR=lib. What CMAKE_INSTALL_PREFIX are you using?

4

I apologize, I think this was a false alarm.

What the code was doing was actually a bit different:

Build with default prefix:

cmake --build .

Install to alternative prefix:

cmake --install . --prefix $HOME/testpref

This is why the x86_64-linux-gnu part stayed in the LIBDIR.

5

Yeah. CMAKE_INSTALL_LIBDIR is determined at configure-time rather than install-time.

6

This has been raised in CMake Issue 23365.