Skip to content

Meaning and Usage of ENABLE_[PACKAGE] flags

In several discussions and issues the question came up how to use the ENABLE_[PACKAGE]=1 compile flags, why are they introduced, what are its implications, and would it be possible to remove these flags completely.

Related issues are:

  • #234 (closed) (handling of config.h)
  • #188 (Fix broken pkg-config files)
  • #161 (Proper usage of add-all-flags macros)

It turns out that the ENABLE_FOO magic gets complicated to handle if different developments are followed: If we decide to remove the config.h file in favor of compiler flags, we cannot have both HAVE_FOO and ENABLE_FOO and the one depending on the other, but just one compile flag. If we always link all packages a separate enable flag would not make sense...

Questions

  • What happens if we add ENABLE_FOO=0 in an upstream module, but compile a downstream module with ENABLE_FOO=1?
  • What is the difference between CMAKE_DISABLE_FIND_PACKAGE_FOO=1 and ENABLE_FOO=0
  • [...]

Partial List of Problems

  • Changing the ENABLE-flag should be possible only for files that are not used in any module library. Otherwise we would get incompatible header and library symbols.
  • Thus it can be used for tests and executables only.
  • It should not be allowed to include any header file that uses a package that can potentially be deactivated.
  • Problematic packages are MPI, Vc, and solvers like suitesparse and superlu if a dune interface is provided.
  • If a dune header is provided that uses a package that can potentially be deactivated, it can be part of a library in downstream module A but the enable-flags changed in downstream module B and you would get a symbol clash

Alternatives

  • Formulate two groups of external packages:
    1. Those that are required by dune code if found and its "enable-flag" should not be changed. Examples: MPI, TBB, Vc
    2. Those that are used only in specific applications. Example: Solvers like SuiteSparse, SuperLU
  • Always activate packages from group 1 if found.
  • Do not activate packages from group 2 by default. The user has to explicitly call something like add_dune_suitesparse_flags(<target>)
  • Once a package is activated for a dune module library, it is a required dependency. Must be added to the target and be exported. The HAVE_FOO flag is not allowed to be changed by the user. If a package should not be used in the first place, it must be deactivated by CMAKE_DISABLE_FIND_PACKAGE_FOO=1
  • Remove all the HAVE_FOO defines from config.h related to group 2 and set these flags as compile definition when add_dune_foo_flags is called.
Edited by Simon Praetorius