Skip to content

How to add include directories to dune targets

Issue

In order to move to a target based build system, our targets need to be equipped with the necessary include directories so that we can stop relying on project-wise include commands (i.e. target_include_directories vs include_directories). Currently, we are using include_directories in dune_project() so that all the targets in the project see the header files of all dependencies and the project itself. This needs to be removed in favor of the target based approach (i.e. target_include_directories). The question here is: what is the best alternative to enforce target_include_directories in all dune modules?

Alternatives

@simon.praetorius made a great summary in !1249 (comment 127842)

There are some ideas how to move the include_directories property from a global property into targets:

  1. Manually setting the include dir to a target. Pro: it is explicit and works right now. Con: Every module needs to create a library. It is quiet a complicated cmake statement to get right. It should actually be something like
target_include_directories(<target> [INTERFACE]
  $<BUILD_INTERFACE:${PROJECT_BINARY_DIR}>
  $<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}>
  $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>)
  1. Extending the function dune_project(<target> [INTERFACE]...) by additional arguments to directly create a module library and set the include directories on this. Pro: expects only little change in the code, can be backwards compatible. Con: now dune_project has two functions, configuring the module and creating a library. See !944 (closed)
  2. Adding a helper function just for the purpose of semiautomatically configuring a module library, e.g., dune_add_module_library(<target> [INTERFACE]...). Pro: clear separation of functionality dune_project vs. dune_add_library but still some automatism. Con: Not yet clear about backwards compatible implementation.
Edited by Santiago Ospina De Los Ríos