#1559 [CMake] Clarify how to switch between sequential and parallel builds
Metadata
Property | Value |
---|---|
Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
Reported at | Jan 30, 2015 14:27 |
Type | Discussion |
Version | 2.3 |
Operating System | Unspecified / All |
Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
Last edited at | Mar 13, 2015 23:47 |
Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
Closed at | Mar 13, 2015 23:47 |
Closed in version | 2.4 |
Resolution | Implemented |
Comment |
Description
I had a look into switching opts files from configure to cmake flags during the last days. Using the compatibility layer works fine, but when you switch to pure CMake flags, some problems arise. I already fixed the most critical issue in http://cgit.dune-project.org/repositories/dune-common/commit/?id=b57a46c0adabdfe4dae8cc6d04972ee66ee76e84 .
However, the variable USE_MPI that the compatibility layer defines is not used throughout the project. So - from CMakes point of view - the issue is the following:
- If you dont provide anything, the build is parallel if an MPI implementation was found, and sequentially otherwise.
- To have a sequential build even with MPI present, you have to add CMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE
However, this contradicts the current Dune-way of having a sequential build by default. To implement this without additional variables, the user could force a parallel build by setting CMAKE_DISABLE_FIND_PACKAGE_MPI=FALSE. Double negation however is a very bad thing!
So, I propose to actually use a variable to toggle between sequential and parallel builds. Not setting the variable will result in disabling the MPI check => sequential build. Setting it, will reenable the check => parallel build.
We now have the opportunity to change this name (as USE_MPI wasnt used anyway). First of all, I would like its value in the documentation to be BOOL (ON/OFF and TRUE/FALSE are equivalent anyway, we might as well be consistent). I like DUNE_PARALLEL as a variable name, because it indicates that it is specific to our build system in contrast to the CMAKE_* variables being features of CMake itself.
Feedback on the issue and the naming is highly appreciated, as this is must have for 2.4 IMO.