compas
Modernize the installation procedure
Background
I guess many of us are thinking about how we could modernize/generalize the installation procedure of the codes. As an example it would be nice to have a system independent compilation configuration instead of compiler and library specific environment files as it is set up now.
I thought we could have such a discussion in this issue.
Collected thoughts and ideas
cmake
Switch to cmake in favour of make (edit: actually, as pointed out by @jagot below, cmake should be thought of more like a Makefile generator) to have a single platform and compiler independent configuration file instead of pre-sourcing compiler specific env files to set env flags. I believe both @mortenpi and @jagot have implemented this at some point? The question is how complicated we want to make things, maybe learning git/github is enough for the developers at the moment. But we should keep this in mind.
The GRASP env variable
@mortenpi suggested that, in the present scheme with the system dependent environment files, we could switch the export GRASP="${PWD}" variable to
export GRASP="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
in order to support sourcing of the env files from a directory different from the GRASP root dir (see here for details). Not sure if this is too complicated for the general user to understand. Let us know what you think, or if you have a simpler solution. EDIT I can't get the above bash command, and variants of it, to work under both Linux and Mac environments, mainly due to slightly different shell implementations. To get the path of the script location one can instead go for python, which should be more consistent, through the os.path.realpath function, e.g.
import os
print(os.path.dirname(os.path.realpath(__file__)))
Re CMake, :+1:, of note is that it does not replace make, it replaces the hand-coded Makefiles. I did this for my repository of ATSP2k.
A good thing is that we don't need to assume a lot about the user's platform, such as which implementation of BLAS/LAPACK to use, etc.
CMake-generated Makefiles tend to be faster as well.
Another option (CMake is not perfect) could be Meson, which I have never used myself though.
You might also look into the role of the $MPI_TMP environment variable. In ATSP it is my recollection that temporary files were sent to this directory, but in GRASP $MPI_TMP is not used at compiled time, only at run-time when the environment variable is not set and so the program switches to the default /scratch/$USER which is fine for me. When I have really long jobs, I never do more than one MPI run at a time, but there are times when I would like to run more than one MPI run and then I need to use the disks option. Or else, I need to learn how to export $MPI_TMP in the script just before running the MPI job.
I have this version of GRASP ported completely over to CMake (https://github.com/mortenpi/grasp). The complete set of commands to compile and install it looks like:
./configure.sh
cd build/
make -j8 && make install
The dependencies between the libraries are set up correctly, so parallel builds work too. And you have access to CTest which makes it easy to set up a suite of unit and integration tests. I could bump it a bit in my TODO list to make a PR for this if there's interest.
Meson would be awesome, but as it is relatively new, it's not readily available in many distros/clusters in my experience. So it would introduce dependencies that many users would have to install manually (Meson and Ninja). But, as long as there is someone to maintain it, we could have parallel CMake and Meson build files.
GRASP env: Not sure if this is too complicated for the general user to understand.
For what it's worth, the oneliner is indeed non-trivial, but but no-one has to touch that, ever. And a few lines of comments should avoid any confusion it might cause.