I'm assuming that this is an oversight as the project uses GNUInstallDirs for other installation paths. Oddly enough, the behavior seems to be correct as long as CMAKE_INSTALL_PREFIX is not /usr:
LIBDIR
object code libraries (lib or lib64)
On Debian, this may be lib/<multiarch-tuple> when CMAKE_INSTALL_PREFIX is /usr.
Here's a small example CMakeLists.txt that shows that it expands to nothing:
-- The C compiler identification is GNU 10.2.1
-- The CXX compiler identification is GNU 10.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMAKE_INSTALL_DIR:
CMAKE_INSTALL_LIBDIR: lib
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/build
Am I misunderstanding how it works and the value of CMAKE_INSTALL_DIR is set somewhere else?
Here's the relevant part of the CMakeLists.txt:
I'm assuming that this is an oversight as the project uses GNUInstallDirs for other installation paths. Oddly enough, the behavior seems to be correct as long as
CMAKE_INSTALL_PREFIX
is not/usr
:Here's a small example CMakeLists.txt that shows that it expands to nothing:
This is what it generates:
Am I misunderstanding how it works and the value of
CMAKE_INSTALL_DIR
is set somewhere else?