[Dune] Improve module handling by CMake

[Simon Praetorius]

Hi,

- I also don't think we should touch the CMakeCache.txt. This is a CMake generated file. It's content might be up to changes when cmake version changes. It's internal. So don't merge or rewrite or generate anything like this manually.

- There is some name irritation in the last mails. You speak about config-files. Do you mean the generated `config.h` file, or do you mean the `PackageConfig.cmake` files? The latter should be the way to go. In those config file, the configuration of a module is layed down, similar to a `FindPackage.cmake` file. It introduces imported targets, the package dependencies and could even set variables of cmake-checks performed in that module (like, if we check for c++ features, this could be done in the dune-common module and then the result be packed into the DuneCommonConfig.cmake file + the annotation that it should not be re-checked again)

- we should work more with imported and exported targets and target properties. External packages should be put as `find_dependency` in the corresponding DuneModuleConfig.cmake file

- If a package is found in module A, it must be a required dependency in module B that depends on module A. This can be set in the corresponding PackageConfig file of module A. If a module was not found in module A, it should not be search for in module B. So, instead of including the ModuleMacros.cmake file that searchs for everything again, we should just put everything in the generated PackageConfig.cmake file that can control whether to search for a module, whether it is required and so on.

- Some of the points above are already implemented in the dune cmake system. Some need improvement. Maybe we can first cleanup the generated DuneModuleConfig.cmake files and see what could be exported there and imported in the `find_package(dune-module)` calles in dependent modules.

- Should we create some kind of working group to go into the details of the cmake system? How could this be organized? I think, sending messages here to the mailinglist is a good starting point, but makes productive discussion complicated. Maybe some topic specific Matrix/Slack/Mattermost/... chat room? Or a GitLab Issue in the dune-common repo?

Best,
Simon

Dr. Simon Praetorius
Institut für Wissenschaftliches Rechnen
Fakultät Mathematik
Technische Universität Dresden
Tel.: TUD-34432
Mail: simon.praetorius at tu-dresden.de
Web: www.math.tu-dresden.de/~spraetor

________________________________________
Von: Dune <dune-bounces at lists.dune-project.org> im Auftrag von Oliver Sander <oliver.sander at tu-dresden.de>
Gesendet: Donnerstag, 30. April 2020 06:51
An: dune at lists.dune-project.org
Betreff: Re: [Dune] Improve module handling by CMake

Hi Christoph,

thanks for the detailed explanation.  Is this sequence of steps
something that people agree upon?

> 1. Use CMakeCache.txt from dependencies to avoid re-running checks in
> later modules.

As a cmake non-expert I am surprised by this.  Are the CMakeCache.txt files
really intended to be used like this from third-party software?

You yourself pointed me to those config-file packages, and I wonder why
we cannot use those?  AFAIU these would solve a separate problem:  I have
gotten reports from people that want to use Dune modules like just another
library.  This fails, because Dune modules don't export the relevant information.

> We need to add some extra sorting, as there is not always
> a unique ordering. Take dune-common, dune-geometry and dune-istl. When
> dune-geometry is run prior to -istl, dune-istl must use -geometry's
> cache and not -common's.

Hmm, wouldn't I just merge the two CMakeCache.txt files and discard
duplicate information?

Best,
Oliver

 Dune-grid has to pick up -istl and so on.
> Easiest solution would be alphabetical sorting of names to get a unique
> ordering.
> After this step, dune modules would know the CMake variables in later
> modules.
>
> 2. Create individual config.h files, for dune-foo this could be
> dune-foo-config.h. For every dependency dune-bar dune-foo-config.h would
> include dune-bar-config.h.  We can stick to config.h, which includes
> dune-foo-config.h.
> After this step, dune modules know the C preprocessor macros.
>
> 3. Improve handling of linking libraries. CMake offers private and
> public interface propagation.
> After this step, linking and passing additional arguments would be more
> CMake-ish.
>
> 4. Fix everything that I currently forgot. Get rid of many Dune-ism,
> that one wouldn't write today, that I am even not aware of.
>
> If others have different ideas, please share them!
>
> Bye
> Christoph
>
> _______________________________________________
> Dune mailing list
> Dune at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune
>