Closed mbanck closed 7 months ago
I think this is addressed in #233 .
CMAKE_INSTALL_LIBDIR
from GNUInstallDirs is left alone and can be overridden by user (no more LIBINT2_INSTALL_LIBDIR
)LIBINT2_
handles. https://github.com/evaleev/libint/pull/233/files#diff-8e69ff48dd421c27038dafc327ded859e9be46b2e1aecec070d8b263a7b03d02R79-R92CMAKE_INSTALL_LIBDIR/pkgconfig/
https://github.com/evaleev/libint/pull/233/files#diff-8e69ff48dd421c27038dafc327ded859e9be46b2e1aecec070d8b263a7b03d02R645 . If you want a variable so that can be adjusted, let me know.Sounds good on first glance; I'm sorry, but I don't have the bandwidth right now to check out that #233 PR, I'll try to give it a spin with respect to distribution packaging ASAP (unless @susilehtola did already?)
I haven't updated libint2 in Fedora since Aug 2019 when 2.6.0 was released...
I've been waiting for the issues with Psi4 (including CMake in libint2) to be addressed
Sounds good on first glance; I'm sorry, but I don't have the bandwidth right now to check out that #233 PR
Sure, no problem. #233 isn't ready for trial yet, and it needs EFV approval, too. I just wanted to record that this issue should be fixed up.
@susilehtola, yes, I'm working on the gmp/mpfr/eigen detection.
This should be minimally addressed in #271 . The library is still going to LIBINT2_INSTALL_LIBDIR because I'm not making unnecessary changes, but the pc file goes to CMAKE_INSTALL_LIBDIR/pkgconfig. Thus locations are adjustable.
The cmake build systems decides to override the standard CMAKE_INSTALL_LIBDIR with LIBINT2_INSTALL_LIBDIR (why?) for the libraries, but it uses a hardcoded
lib/pkgconfig
directory forlibint2.pc
(but see #225 - the generatedlibint2.pc
is broken anyway):This leads to
libint2.pc
not ending up in the same place as the library (they go into/usr/lib/<gnu-triplet>/
on most distributions in order to support multiarch).