Add BUILD_INTERFACE to paths registered on the package registry

Testing on the dumux pipeline showed that the finding the dune package was adding the include directories as raw strings in the package registry. This caused installed targets linked against all dune packages to contain build directories even after being installed. That's obviously wrong as build directories may not exist when the packages are installed. The offending line is already removed in master, but not for release 2.10 (see !1457). So this changes adds the `BUILD_INTERFACE` to fix the problem, and an opt-in in case someone was relying on the previous behavior.

Note that raw string in the registered include directories are technically a ~bug. However, in favor of stability wrt 2.10 release we keep the current behavior and add a flag (`DUNE_REGISTER_DUNE_DEPENDENCIES_WITH_BUILD_INTERFACE`) to enable the `BUILD_INTERFACE` generator expression when linking targets that will be exported.

cmake/modules/DuneEnableAllPackages.cmake

@@ -87,7 +87,10 @@
 #
 #    Adds all currently registered package flags (see :ref:`dune_register_package_flags`) to the given targets.
 #    This function is mainly intended to help write DUNE modules that want to use :ref:`dune_enable_all_packages` and
-#    define their own libraries, but need to be compatible with CMake < 3.1
+#    define their own libraries, but need to be compatible with CMake < 3.1.
+#    If this function is used on an exported target, make sure to enable
+#    `DUNE_REGISTER_DUNE_DEPENDENCIES_WITH_BUILD_INTERFACE` to ensure that build include directories of dune projects
+#    are not propagated on the installed targets.
 #
 # .. cmake_function:: dune_register_package_flags
 #

cmake/modules/DuneModuleDependencies.cmake

@@ -56,6 +56,21 @@ Macros to extract dependencies between Dune modules by inspecting the
   Include the corresponding ``Dune<module>Macros.cmake`` file of all
   dependencies if this file exists.
 
+
+.. cmake:variable:: DUNE_REGISTER_DUNE_DEPENDENCIES_WITH_BUILD_INTERFACE
+
+    This variable can be used to control whether the finding of dune modules registers
+    their include directories as raw paths or as `BUILD_INTERFACE` generator expression.
+
+    This option is only present in patches of the 2.10 release as future versions do not register
+    include directories in the dune package registry and this problem does not occur
+    (see https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1457).
+    Since upstream modules are imported dependencies, they must should not be exported
+    through the registry either, therefore the `BUILD_INTERFACE` is required if a target is linked
+    against the registry and installed. However, if the the contents of the registry are parsed
+    manually, the `BUILD_INTERFACE` may break such parsing. So this option allows to opt-out of the
+    "correct" behavior in case it's necessary.
+
 #]=======================================================================]
 include_guard(GLOBAL)
 
@@ -63,6 +78,11 @@ include(DuneEnableAllPackages)
 include(DuneModuleInformation)
 include(DuneUtilities)
 
+option(DUNE_REGISTER_DUNE_DEPENDENCIES_WITH_BUILD_INTERFACE
+  "Controls whether the finding of dune modules registers their "
+  "include directories as raw paths or as `BUILD_INTERFACE` generator expression."
+  OFF)
+
 # checks that a module version is compatible with the found version of a module
 # notice that this has the side effect of populating the ${module}_VERSION information
 macro(dune_check_module_version module)
@@ -201,7 +221,11 @@ macro(dune_process_dependency_macros)
       endif()
 
       # register dune module
-      dune_register_package_flags(INCLUDE_DIRS "${${_mod}_INCLUDE_DIRS}")
+      if(DUNE_REGISTER_DUNE_DEPENDENCIES_WITH_BUILD_INTERFACE)
+        dune_register_package_flags(INCLUDE_DIRS $<BUILD_INTERFACE:${${_mod}_INCLUDE_DIRS}>)
+      else()
+        dune_register_package_flags(INCLUDE_DIRS "${${_mod}_INCLUDE_DIRS}")
+      endif()
     endif()
   endforeach()
 endmacro(dune_process_dependency_macros)