Moving the source code of external programs into submodules

jussiks commented 4 years ago

Source code of all external programs should be in their own individual repos under JYU-IBA and added as submodules to the potku repo. This allows developing those programs individually and using the same code across multiple projects.

This issue is for progress tracking and general discussion and suggestions.

Following programs should be added as submodules:

[X] Jibal
[X] MCERD
[X] get_espe
[ ] tof_list
[ ] erd_depth
[ ] coinc

gsto has been replaced by get_stop (which gets installed along with Jibal). Unused source code should of course be removed from potku repo.

Build scripts

Automated build scripts (build.sh and build.bat) need to be updated whenever new submodules are added. Feel free to suggest additional build parameters and command line arguments.

Data files

Data files are currently located in external/share and external/share/jibal folders. We need to decide on which data files to use during development and how to ship the files with the binary distribution.

Somewhat confusingly Jibal uses external/share/jibal/masses.dat and external/share/jibal/abundances.dat while Python code and older C programs use external/share/masses.dat. The latter file contains both masses and abundances. Python code could be refactored to use the same files as Jibal but I do not know about the other programs.

Currently Potku still needs the srim2013.tot file which was previously located in external/Potku-data. This file should be copied into external/share (this file is not in source control).

External folder

The names of subfolders in external have changed. If you are working with a previously cloned version of potku, you may have folders like Potku-bin, Potku-include, Potku-lib and Potku-data. These are no longer needed so you can remove them.

jussiks commented 4 years ago

Note to self: .spec files are not working with the new folder structure. Need to fix those.

jaakkojulin commented 4 years ago

The old masses.dat will be removed too, as soon as erd_depth is upgraded and tof_list is replaced. Python code should either use the same files as Jibal or get the isotopic data from Jibal library (needs some library wrapper Python) or by piping the output from e.g. jibaltool isotopes.

jaakkojulin commented 4 years ago

A version of erd_depth using Jibal is available now at https://github.com/JYU-IBA/erd_depth . It might not work very well yet and doesn't include tof_list.

jaakkojulin commented 4 years ago

Note to self and to everybody else. If you have installed Jibal somewhere in your system (so that CMake can find it) it is possible that when MCERD is compiled the system version of Jibal is used rather than the one in Potku submodules.

It might be possible to try to make the "local" version preferable with CMake configuration, but it is not easy.

This issue is potentially made worse by this line in build.sh:

https://github.com/JYU-IBA/potku/blob/9f337b14a05f8070b631057da2ee4c025d83c99d/build.sh#L24

Specifically, the CMAKE_INSTALL_RPATH enables MCERD to find the dynamically loaded Jibal library from the Potku distribution. However now MCERD can not find the dylib (on macOS) of Jibal library that it was compiled against! This causes binary compatibility issues if there have been changes in the headers. Removing CMAKE_INSTALL_RPATH makes mcerd work properly with system Jibal, provided that the versions are source code compatible.

Possible mitigation strategies:

[x] 1. Make MCERD depend on a minimum version of Jibal. This way old versions installed in the system are possibly ignored. However newer versions aren't. Depending on an exact version number is a nightmare for developers.
[ ] 2. Use more sane SOVERSION in Jibal so that when the API changes you need a different version of the library. This should allow us to ignore newer versions of Jibal when running e.g. MCERD.
[x] 3. Prevent MCERD shipped with Potku from compiling against system Jibal (see https://github.com/JYU-IBA/potku/issues/40#issuecomment-640513570)
[x] 4. Make compilation of MCERD output explicitly where Jibal was found
[x] 5. Make MCERD output the version number of Jibal it was compiled against and version number from the library (runtime).

jaakkojulin commented 4 years ago

Turns out that setting CMAKE_PREFIX_PATH is actually necessary. Previously I suggested setting CMAKE_INSTALL_PREFIX and while the latter also adds the EXT_DIR directory to search path, the directory does not take preference over the system directories.

Changes are tested in external_update branch

jaakkojulin commented 4 years ago

These build issues and bugs related to get_espe density/fluence parameters possibly fixed in pull request #42.

JYU-IBA / potku