Skip to content

Discrepency between lib and lib64 install paths  #428

@wavefunction91

Description

@wavefunction91

As was introduced in #404 and amended in #426, current CMake best practice is to use GNUInstallDirs over hardcoded paths in CMAKE_INSTALL_XYZ. The issue is that not everyone does this uniformly, so care has to be taken when deciding where install paths actually get delegated to.

On some architectures (have yet to figure out how this is decided by cmake), GNUInstallDirs sets CMAKE_INSTALL_LIBDIR to lib64 rather than lib. This is a problem as many of the hardcoded install paths for dependencies assume lib. With my local (non-GPU) install, that list seems to contain:

  1. MADNESS
  2. Umpire
  3. BTAS

However, this issue is actualyl a bit deeper as not only to these dependencies not respect GNUInstallDirs (which could be argued to be unnecessicary) - they don't respect CMAKE_INSTALL_LIBDIR, which is a much graver issue.

From a top-level install, this can be resolved by hardwiring the install paths upon fetch. For example, I've been able to get (most) of MADNESS to install to a custom LIBDIR by adding the lines

diff --git a/cmake/modules/FindOrFetchMADWorld.cmake b/cmake/modules/FindOrFetchMADWorld.cmake
index 7be76bac..0d1de5dd 100644
--- a/cmake/modules/FindOrFetchMADWorld.cmake
+++ b/cmake/modules/FindOrFetchMADWorld.cmake
@@ -20,6 +20,13 @@ if (NOT TARGET MADworld)
   set(ENABLE_MEM_PROFILE ON CACHE INTERNAL "Whether to enable instrumented memory profiling in MADNESS")
   set(ENABLE_TASK_DEBUG_TRACE ${TILEDARRAY_ENABLE_TASK_DEBUG_TRACE} CACHE INTERNAL "Whether to enable task profiling in MADNESS")
 
+  set(MADNESS_INSTALL_BINDIR "${TILEDARRAY_INSTALL_BINDIR}"
+        CACHE PATH "MADNESS binary install directory" FORCE)
+  set(MADNESS_INSTALL_INCLUDEDIR "${TILEDARRAY_INSTALL_INCLUDEDIR}"
+        CACHE PATH "MADNESS INCLUDE install directory" FORCE)
+  set(MADNESS_INSTALL_LIBDIR "${TILEDARRAY_INSTALL_LIBDIR}"
+        CACHE PATH "MADNESS LIB install directory" FORCE)
+
   # Set error handling method (for TA_ASSERT_POLICY allowed values see top-level CMakeLists.txt)
   if(TA_ASSERT_POLICY STREQUAL TA_ASSERT_IGNORE)
     set(_MAD_ASSERT_TYPE disable)

The pkgconfig still gets installed to lib, but I suspect that's fixable. I'd assume that. Umpire should be straight forward, but BTAS is a bit of a pain as it installs a blaspp_header target to lib that clashes with blaspp's lib64 install path and breaks discovery.

The alternative is to require that CMAKE_INSTALL_LIBDIR is lib to maintain consistency - some people may not like that, but its a short term band-aid that seems to work

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions