plumed
CMake build system
It's not an issue, but feature request, I think.
As for now PLUMED uses ancient autotools build system which have some well-known problems such as mystic syntax, hard debuggability, issues with cross-compiling and extra overhead (redundant checks, somewhat strange test approach and so on).
I think moving to the CMake build system could help us to solve some of the problems above and prepare for future changes while conservative autotools does not.
What do you think?
I actually like the autoconf philosophy:
- Developers write
configure.acin a high level language and "compile it" toconfigure. - Users just have to run
configure, which is a portable shell script.
As a user, I always found it slightly easier to install programs using autoconf wrt programs using cmake.
I agree that the "high level language" is pretty cryptic, with a mystic syntax, and a bit difficult to debug. I am not aware of issues with cross compiling (we regularly cross compile with conda build), and the extra overhead to me seems totally not an issue. Cmake has its own drawbacks as well. Asking users to install an extra program (cmake), with its own version requirement, is a small but not negligible obstacle. The strange way cmake handles isysroot in MacOS builds on conda made me waste some time in the past to build a LAMMPS recipe.
Overall I am not sure the transition would be worth. But if someone wants to try I am happy to guide through the current configure/build/install systems.
Currently, we only use autoconf to build Makefile.conf, and everything else is handled with a combination of shell scripts and makefiles. Do you know if cmake allows you to do the same so as not to need to translate both configuration and build/install system at the same time? Also notice that the configure system is fully implemented in configure.ac, so it's not too difficult to check if all the needed features are portable to cmake, whereas the build/install scripts are scattered here and there and fairly complicated.
Ok, I understood your position, thank you!
Regarding installation of extra programs: actually not every system have autotools installed so sometimes users should install toolchain by hand. I think CMake and AutoTools approach are equal in this aspect.
I have almost no experience with MacOS so can't say anything about CMake and MacOS interaction. Perhaps now things have become fixed and there is a little chance to face troubles with that.
May be I misunderstand you, but CMake allows you to generate configuration headers (and another files) during build preparation so it shouldn't be a problem.
You're talking about combination of shebangs and makefiles and this is the point which worries me. I think that they are custom scripts and in my experience I've faced some issues with several packages in the past which have been using the same approach. PLUMED is not one of them but as for me this way could be potentially dangerous and quite fragile. Though using CI smooths this potential issue...
Regarding modularity: I think partitioning of solid installation script into independent parts could give us more control. E. g., you could carry out documentation build, core build, bundled libs compilation and so on into separate installation scripts which are easier to maintain. I surmise that current build system is doing quite the same thing but as for me keeping installation recipes in one language/dialect/style will provide more transparent way for maintaining.
Regarding installation of extra programs: actually not every system have autotools installed so sometimes users should install toolchain by hand. I think CMake and AutoTools approach are equal in this aspect.
This is not true, actually only developers need to install autotools. Users only need a shell. This is the very fundamental difference between the two approaches. If you need to compile PLUMED on a cluster, you will need to install cmake there first. I had troubles in the past installing the at that time recent cmake version required by gromacs, for instance. I think this is an intrinsic disadvantage of cmake.
I think that the current PLUMED configure system is fine. The configure.ac is kind of readable. Any complicated test can be coded with a few lines of shell scripting. This could be replaced with cmake I guess, but I cannot get the real advantage.
The current build/install system is kind of scaring and, as you see, very fragile, I totally agree. But it gives us the flexibility to do a lot of stuff. Is cmake able to handle all of those in a standardized way? If yes, I see the advantage, and removing the current mess would compensate for the disadvantage above. If not, we would have to used a mixture of cmake configuration + shell scripts. It will be one dialect more rather than one less, and in the end will be more difficult to maintain.
A few comments about modularity:
Separate documentation build: due to the way the documentation is built, you need to compile plumed first. So this cannot be bypassed by using cmake.
Bundled libs compilation: we don't really have what people would call bundled libs, because the source code of the bundled libraries has been modified to keep everything in the PLMD namespace. So they are part of the plumed code, and not installable or usable separately.
Yes, CMake allows you to do in-file scripting in its own language and provides you with flow control and another syntax tools.
Generally your points sound reasonably. Anyway, it's not high-priority task and I just wanted to hear your position. Thank you!
I would keep this open, because I think this is something that even if with low priority we should consider. Something I like a lot of CMAKE is the possibility to have multiple configurations ready to be compiled. This is very useful for debugging for example.
@carlocamilloni about the "multiple configurations ready to be compiled", is it out of source compilation? In principle also autoconf allows it. I would be happy to simplify our build process so that we decrease the number of "ad hoc" steps, going in the direction of allowing out-of-source builds with autoconf. In the end, if we manage to simplify the build process, even a later transition to cmake would be easier (if we decide for it).
The whole building process with CMake narrows down to perfect out-of-source compilation:
mkdir build
cd build
cmake <PARAMS> ..
make
make install
Source tree (according to the CMakeLists.txt) is copied into build directory so original source directories are not populated with intermediate objects
To make it clear: also autoconf allows out-of-source build. Actually this is a feature of make.
The point is that our build system is too complicated to do this in the simplest way. For instance, some of our source files are built (e.g. src/core/PlumedMainEnum.inc).
Just to quote another thing that I don't like much of cmake: in-source builds are not even allowed in cmake.
I don't have big concerns against cmake and I would be happy to (slowly) make the transition, I am just saying that the reason should not be the wrong one. I would definitely prefer to start enabling out-of-source build in autoconf, if this is what we need, since it will be much much simpler. The steps needed to enable this in autoconf will be a clean up needed also if we want to transition to cmake.
Another comment: source tree is not copied by cmake (at least: gromacs does not do that). It does a standard out-of-source build using the make command, keeping the source files as dependencies. Copying files would be totally useless, as you would not track dependencies anymore.