Skip to content

Split config file into public and private config files

Santiago Ospina De Los Ríos requested to merge feature/generate-and-install-config-file-per-module into master

Description

This is a proposal to handle the configuration files and solve #234 (closed). With this we will be one step nearer to have a downstream project that can be completely independent of the DUNE build system.

Proposal

  1. Generate a public and a private configuration files for each module (easy to automate since config files already have those definitions)
    • Public dune-foo-config.hh: Contains the definitions needed for its usage in downstream modules, including upstream public configuration files (e.g., #include <dune-grid-config.hh>). This header is installed and guarded to be included once.
    • Private dune-foo-config-private.hh: Includes the public header (e.g., #include <dune-grid-config.hh>), and the module information that should not be exported nor be visible outside of the module (same role as #include "config.h"), thus is not installed.
  2. The module only installs the public header.
  3. Downstream can consume these headers independent of the build system they choose for their project.

Goal

The main driver for this changes is the following snippet:

cmake_minimum_required(VERSION 3.16)
project("dune-foo" CXX)

# find dune-bar project: exports the target Dune::Bar
find_package(dune-bar)

# create a target library with native cmake
add_library(dune-foo INTERFACE)

# link to dune targets without need of dune-isms (e.g., custom generation of config files)
target_link_libraries(dune-foo INTERFACE Dune::Bar)

See !1249 (merged) for more info on other steps to achieve this. Please take into account this when proposing alternative solutions.

Backward compatibility

This MR is intended to be backward compatible. This is achieved by providing config.h with the same content as before, but additionally with pre-prorcessor guards to avoid double definitions.

  • Projects that do not need compatibility with DUNE 2.9 can immediately use the new header files.
  • Projects with compatibility with DUNE 2.9 need to stick using the config.h header file because the new header files do not exist in older versions. However, once compatibility with DUNE 2.9 is dropped (e.g., in DUNE 2.12), we can deprecate the old legacy headers and inform people that they need to use the new headers.
  • Projects that define variables that are later changed (e.g. new packages were found and config depends on it) are backwards compatible, but they need to include config.h first (see documentation). See !1294 (merged) for an alternative of handling this situation.

Closes #234 (closed)

Needs

Python CI: https://github.com/dune-project/dune-testpypi/actions/runs/5350425239

Edited by Santiago Ospina De Los Ríos

Merge request reports