[Dune-devel] Evolution of the CMake environment

[Markus Blatt]

Hi,

Anything that makes the buildsystem more CMake aligned is highly
appreciated. But we need to make sure that this does not mean that
we force even more DUNEisms onto downstream modules. Some for example
perfer to not include DuneMacros.cmake at all but do everything on
their own to have full control.
Also we have to aware that some projects need to be support multiple
DUNE/buildsystem versions (e.g 2.6-2.8 + master). Which is quite
challenging.


Am Sun, Feb 06, 2022 at 01:49:38PM +0100 schrieb Simon Praetorius:
>
>1. What have we achieved (since the last meeting):
>
>- The big `DuneMacos.cmake` file is split up into several files 
>containing only a few interface function plus related implementation 
>details (This simplifies the cmake development significantly and 
>revealed some historic outdated macros that could be removed)
>- Some deprecated and outdated macros and functions are removed to use 
>more modern 3.13 version implementations
>- Several `Find<Package>` modules are rewritten to provide a common 
>style, documentation, and imported targets to link against. Those 
>often have the name `<Package>::[<Package>|<Subpackage>]`.
>- The output during cmake configuration is reduced, e.g., by moving 
>some operations to doc targets, or print messages into a logfile 
>instead of stdout
>- The important cmake function `dune_add_library` is rewritten and 
>cleaned up. It is the main workhorse for creating dune module 
>libraries and lead to a simplification of several main CMakeLists 
>files.
>

This was very good. Of course the consequent use of imported targets
while still relying on DuneMacros.cmake introduced some work downstream
(Add the same targets to the custom find modules). But that is the
price you have to pay if you choose to go down that road and support
multiple DUNE versions.

There is of course the tendency for projects using CMake to implement
their own find package modules because Kitware does not want to include them.
Maybe each of these user projects even uses different target names for
the same thing.
That is very unfortunate and might blow-up when combining those.

Maybe we should contribute CMake package configuration files to upstream
projects missing them, or push them to make their own. That would help a lot.


>2. What is proposed and planned:
>
>a) I propose a cleaner mechanism for setting the c++ standard for the 
>compiler, by adding a target feature requirement. This allows to 
> [...]
>enforce this. See
>https://gitlab.dune-project.org/core/dune-common/-/merge_requests/862

Nothing to add that has not been added to gitlab. We should make
clear in changelog that enforcement only works for code with a direct
dependency on a dune library.

>
>b) I propose to make a dune module target a special supported/featured 
>target. All dune modules should have a targets the contains the module 
>[...]
>https://gitlab.dune-project.org/core/dune-common/-/merge_requests/944.
>

Sounds good.

>
>c) I propose to define a namespace for dune module targets, like 
>`Dune::`. Namespaces are very common in cmake, see external package 
>imported targets above, and thus should be provided by Dune as well. A 
>namespace target is typically just an alias to an internal library 
>target, i.e., `Dune::common -> dunecommon`, or it is an imported 
>target when used in a downstream module. There, the former "internal 
>library target" is not visible any more. Advantages for such a 
>namespace structure: it follows the pattern of most other libraries, 
>it groups the targets into a namespace, instead of setting a prefix to 
>the name itself, it prevents from linking against an unknown dune 
>module since a target must be available.
>
>Some consequences and discussion:
>  * The name that comes after the :: needs to be decided on. It is 
>made flexible in the `dune_add_library` function and in MR!944 by 
>providing an option "EXPORT_NAME". There is a default (if nothing else 
>is specified) that is the project name without the "dune-" prefix. 
>Other discretization modules could set their own export name, e.g. for 
>dumux or amdis. But, if you are using the `dune_project` macros, the 
>namespace will always be `Dune::`
>  * We have actually already > 2 spellings of dune modules that we are 
>using in cmake, e.g., "dune-common", "dunecommon", "DUNE_COMMON", and 
>now additionally "Dune::common". This gets complicated and it is not 
>easy to guess which spelling to use in which location. Thus, I propose 
>to remove the `dunecommon` in favor of `dune-common`. Note, this is 
>unrelated to the filename of the created library. That one can be set 
>by the option `OUTPUT_NAME` in dune_add_library` and `dune_project`.

This has to be backwards compatible. Currently there are already targets
with the same name as the library but without the lib part (dunecommon for
libdunecommon). That made using this rather easy as it is backwards
compatible. I do not see a reasong to remove these as proposed here.
Please keep them as an alias for the more fancy ones.

>
>d) I propose to move the cmake commands currently written in the 
>`Dune<Module>Macros.cmake` file, into the `dune-<module>-config.cmake` 
>file. This can be done by automatically including the "old" Macros 
>file. By having all the macros now directly in the config file, a dune 
>package can be used in a project without including all the other 
>dune-common cmake functions and without using `dune_project` and even 
>without writing a `dune.module` file. There is still some work to do 
>to get this running but the steps are already clear.
>
>Some consequences:
>  * The `dune-<module>-config.cmake` file will be used by any 
>`find_package(<module>)` call. Thus no need to manually include 
>anything. Also it is not necessary to include the old Macros file 
>again, because it is already included in the config file
>  * I will try to make this an transparent change, i.e., a config file 
>is already created automatically. This file will be extended by these 
>additional includes. Only if you are writing your own 
>`dune-<module>-config.cmake` file you have to add a few lines there. 
>This will be documented once the implementation has some progress. I'm 
>thinking about a smooth transition but this needs to come up once a 
>draft is implemented.

I think the goal is good, but the path to it is wrong or in the wrong order.
By calling DuneMacros.cmake in the package configuration file it is not
possible to not see the Duneisms of the buildsystem anymore (e.g. the
override of add_test). We are actively forcing them on our users. That is
at least rude but might also break projects.

Please first get rid of any Duneisms needed to linke/compile against a DUNE
library. Then we can have slim package configuration files that consisting
only of some variables, the targets and a generated list of find_dependency 
(CMakeFindDependencyMacro.cmake) calls for the dependencies that were found
and used for the module.

Then this will indeed make usage of DUNE a great deal easier. (Currently we
are relying on the fact that everything that was found / not deactivated for
the upstream core modules is also in the same state for the downstream modules.
That is a bit fragile.)

Markus

-- 

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858