Provide a cmake utility dune_default_include_directories

Summary

This MR adds a cmake macro dune_default_include_directories that allows to set target include-directories that are common to dune modules directly. It is a helper macro to simplify configuration of module targets. Additionally, this MR removes the need for global include_directory commands in dune_project that can be controlled by a policy flag.

Usage

In your main CMakeLists.txt you can add default include-directories on a given target, e.g.

# Create a target
dune_add_library(dunecommon EXPORT_NAME Common NAMESPACE Dune::)
# set include directories
dune_default_include_directories(dunecommon PUBLIC)

The scope PUBLIC can also be replaced by PRIVATE or INTERFACE.

If the target is a module library, one can omit the global include_directory command and instead rely on the target propagation of include-dir properties. To deactivate the global includes, you can set the dune policy DP_DEFAULT_INCLUDE_DIRS to "NEW":

# after the include of DuneMacros and before calling dune_project()
dune_policy(SET DP_DEFAULT_INCLUDE_DIRS NEW)

This will deactivate the displayed warning about unset policies and will remove the <module>_INCLUDE_DIRS variable from the <module>_config.cmake file.

If you don't want to set the include directories explicitly and prefer the old behavior, you can also set

dune_policy(SET DP_DEFAULT_INCLUDE_DIRS OLD)

to silence the warning.

Discussion

• If the include-dirs are moved to the target, it can be removed from the global environment. Additionally, the variable <module>_INCLUDE_DIRS is removed from the <module>-config.cmake file. The is a trick to not set this automatically after find_package(<module>) is called. IMHO, the find_package should not change the environment automatically.
• The NEW behavior is not enforced. Only when we release dune 2.12 it will be the default behavior.
• Having include-directories on imported targets make these automatically to "SYSTEM" includes. This means that warnings in code from these libraries are not shown anymore. We have to find a way to change this. In cmake >= 3.25 we can add EXPORT_NO_SYSTEM, see https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_NO_SYSTEM.html (solution: use NO_SYSTEM_FROM_IMPORTED on dune libraries)

Close #332 (closed)

added buildsystem label

There are some aspects that need to be discussed. Thus, I think it is not for Dune 2.10 anymore.

added 1 commit

• c0a5317a - make the include_private a private include directory

Compare with previous version

changed the description

added 1 commit

• 4df450e8 - Add a documentation of a set policy

Compare with previous version

added 1 commit

• 5ecf2c4b - In global include dir for generated files in the binary dir

Compare with previous version

changed the description

resolved all threads

marked this merge request as ready

Open discussion:

Having include-directories on imported targets make these automatically to "SYSTEM" includes. This means that warnings in code from these libraries are not shown anymore. We have to find a way to change this.

In cmake >= 3.25 we can add EXPORT_NO_SYSTEM to the exported dune libraries, see https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_NO_SYSTEM.html, or NO_SYSTEM_FROM_IMPORTED to the importing dune libaries, see https://cmake.org/cmake/help/latest/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html. Both have drawbacks:

1. EXPORT_NO_SYSTEM requires cmake 3.25. It also sets this as a property to the imported target, thus a library just consuming dune also gets included as non-system includes, e.g. sees all warnings generated inside of dune header files
2. NO_SYSTEM_FROM_IMPORTED (is available in earlier cmake version). It is the logic opposite to the EXPORT_NO_SYSTEM property. If set, all libraries are non-system libraries and we get all warnings.

Maybe a compromise would be either enable all warning only in Debug builds or to have a policy that controls the behavior, or a cmake option to enable the warnings from all upstream modules and external libraries.

changed the description

resolved all threads

changed the description

I have found the reason for the strange error in the pipeline. When compiling the test dune/common/test/concepts.cc an executable concepts is created in the corresponding build folder. Now, this directory is also included (I need to check why and from where). That means, that there is a file "concepts" in the include path that is an executable and not the std c++ library concepts that I wanted to include. Possible solution: rename the test source file to conceptstest.cc and make sure that there is no other source file with a corresponding std library header filename equal to the test target name.

Better solution: don't add this directory to the include path list.

added 23 commits

• 5eac842b...1a5d581f - 17 commits from branch master
• 0d13f3cb - Provide a cmake utility dune_default_include_directories
• e8aa2236 - make the include_private a private include directory
• a5ab7091 - Add a documentation of a set policy
• a40a2800 - In global include dir for generated files in the binary dir
• 00e58047 - Add property NO_SYSTEM_FROM_IMPORTED to dune libraries
• 34c93eb0 - Remove global include directories in dune_instance generator

Compare with previous version

added 1 commit

• ba983d55 - Remove target_include_dir from dune-instance generated targets

Compare with previous version

added 1 commit

• 225b7dfc - Add file to CMakeLists

Compare with previous version