simsopt icon indicating copy to clipboard operation
simsopt copied to clipboard

Instructions for compiling simsoptpp with CMake are outdated

Open kchammond opened this issue 9 months ago • 1 comments

The documentation (docs/source/cpp.rst) provides some helpful instructions for how to compile changes to the C++ code without having to do a full reinstall of simsopt. These have worked for me in the past, but for more recent versions, they do not work anymore.

The issue is related to the location of the shared object file for simsoptpp. According to the instructions, it is assumed that the initial compilation (e.g. pip install -e .) should have created a shared object file in the src directory. The instructions say to replace this file with a soft link to the updated shared object file generated by make -j. However, when I compile the latest versions with pip, no shared object file is stored in src. Rather, it is stored in a subdirectory of the virtual environment instance under which the compilation with pip is performed.

I will note that an additional copy of the shared object file is stored in a subdirectory of the build directory in the repository directory (build/cp312-cp312-linux_x86_64). However, this file does not appear to be used by simsopt. Replacing it with a soft link has no effect on the execution of Python scripts that call simsoptpp functions. The key file to replace seems to be the one in the virtual environment directory as described above.

The following alternate set of commands works for me, both on my Mac laptop and on a Princeton Linux cluster:

# Same as before:
git clone --recursive [email protected]:hiddenSymmetries/simsopt.git
cd simsopt
pip3 install -e .
mkdir cmake-build
cd cmake-build
cmake ..
make -j

# Proposed replacement:
cd [path-to-virtual-environment]/lib/python3.12/site-packages
rm simsoptpp.cpython-312-x86_64-linux-gnu.so
ln -s [path-to-simsopt-repo]/cmake-build/simsoptpp.cpython-312-x86_64-linux-gnu.so .

As a caveat, the name of the .so file and the subdirectory name that includes the Python version ("python3.12") will likely vary from one computer to the next.

I'd be interested if others have experienced this issue and/or have thoughts on how to address the somewhat more convoluted procedure in the documentation.

kchammond avatar Apr 16 '25 16:04 kchammond

@kchammond I believe the updates to build tools could have caused this change in behavior. The documentation should be updated to reflect this. Can you please update the docs and submit a PR?

Thanks

mbkumar avatar May 08 '25 14:05 mbkumar