Use cmake-build-extention

[twhitehead]

This is just a suggestion, but as someone who just finished building you project for one of our user's on the Canadian super computer systems where conda is entirely broken and setting LD_LIBRARY_PATH causes a lot of pain, I think your project could really benefit from using the setuptools cmake-build-extension.

Ideally then an install could then become as easy as

pip install .

inside a virtual environment, and there would be no need to mess around with PATH, LD_LIBRARY_PATH, or PYTHON_PATH to use to package as well.

[alexvakimov]

Thank you, Tyson @twhitehead . We'll consider such a thing. If you have any recipes for building/installing Libra package on your cluster, and you think this would be useful to other users, we'd appreciate if you could share them here or via a pull-request to one of the README.md files

[twhitehead]

@alexvakimov thanks for you kind response. It isn't actually too bad to build on any of the Compute Canada (now Digital Research Alliance of Canada) clusters. Here are the directions (updated 2024-07-04 to uses the older environment, python 3.7, and clean up the CMAKE_MODULE_PATH bit).

1. Load the modules for the dependencies

$ module load StdEnv/2020
$ module load gcc python/3.7 boost/1.80.0 libint eigen

2. Create a new virtualenv in install libra into and update pip

$ virtualenv libra
$ source libra/bin/activate
$ pip install --no-index --upgrade 'pip < 21.0'

3. Get a copy of the libra-code repo

$ cd libra
$ git clone https://github.com/Quantum-Dynamics-Hub/libra-code.git
$ cd libra-code

4. Update CMakeLists.txt to use

FIND_PACKAGE(Boost REQUIRED)

FIND_PACKAGE(Libint2 REQUIRED COMPONENTS shared gss impure_sh onebody_d0_l6 g12_d0_l4
g12_d1_l4 eri_c4_d0_l5 eri_c4_d1_l4)

5. Build libra-code

$ mkdir build
$ cd build
$ cmake -D
CMAKE_MODULE_PATH=$EBROOTLIBINT/lib/cmake/libint2 \
      -D PYTHON_LIBRARY=$EBROOTPYTHON/lib/libpython3.7m.so \
      -D PYTHON_INCLUDE_DIR=$EBROOTPYTHON/include/python3.7m ..
$ make -j 8

6. To use you need to set PYTHONPATH (DO NOT SET LD_LIBRARY_PATH!)

$ export PYTHONPATH=$(pwd)/src:$PYTHONPATH

[alexvakimov]

Thank you, Tyson, @twhitehead for such nice instructions. We shall try that out. I just wonder what kind of problems did you run when you were setting the LD_LIBRARY_PATH to point to the built binaries?

[twhitehead]

We run a mix of glibc versions. All our binaries are compiled with RPATHs so they can find their libraries (our compilers are actually all wrapped to insert PPATHs to libraries). Setting LD_LIBRARY_PATH generally breaks stuff as it overrides the RPATHs, causing program to suck in libraries that have conflicting base library requirements.

In your case, there is just the liblibra_core.so in that directory, so it is extremely unlikely it would cause any issues. Unfortunately there are lots of cases this is not the case and documentation tells our users to set LD_LIBRARY_PATH.

So we try and get them to not set it unless they really need to, in which case we would look at either creating a wrapper that just sets it for that executable or, sometimes a wrapper won't work as it is inherited by any processes that process starts, even use patchelf to insert the required path as an RPATH.