Uploaded image for project: 'ROOT'
  1. ROOT
  2. ROOT-8062

Add INTERFACE_INCLUDE_DIRECTORIES and namespacing to exported/imported CMake targets



    • New Feature
    • Status: Closed (View Workflow)
    • Medium
    • Resolution: Fixed
    • 6.06/02
    • 6.13/01
    • Build System
    • None
    • All


      I'd like to request that ROOT's CMake package configuration files add usage requirements
      for the created imported targets. This would require a bump in the minimum CMake version for building ROOT itself to 2.8.12, but shouldn't affect clients of an installed ROOT using 2.8.8 or similar.

      The main usage requirement I'd like to request is use of the INTERFACE_INCLUDE_DIRECTORIES property on targets, that can be set using the target_include_directories command:


      This can help both internally and externally as setting the include directories on a target means a client of the target does not need to explicitly call include_directories. For example, instead of doing

      find_package(ROOT REQUIRED)
      target_link_libraries(MyTarget ${ROOT_LIBRARIES})

      a client can simply do

      find_package(ROOT REQUIRED)
      target_link_libraries(MyTarget ${ROOT_LIBRARIES})

      and CMake will handle adding the requisite include paths to the compilation of {{MyTarget}}s sources.

      I'd also like to request a "namespace" for the ROOT imported targets both to avoid name clashes and to clarify the origin of a consumed target in client scripts, e.g.

      In ROOT

      export(... NAMESPACE ROOT:: ...)
      install(EXPORT <exportsetname> NAMESPACE ROOT:: DESTINATION ...)

      A client can then do, for example

      Client Package

      find_package(ROOT REQUIRED Physics)
      # Client package's Physics lib
      add_library(Physics ...)
      target_link_libraries(MyTarget ROOT::Physics Physics)

      and not have a name clash between the internal and ROOT targets. Clients using the ROOT_LIBRARIES variable are not affected as the namespacing is hidden to them.

      The additional benefit here is that usage requirements are transitively applied and have public/private scope, so if the Client package exposes ROOT in its interface, it only needs to re-find ROOT in its own "ClientPackageConfig.cmake" file rather than manually configure/set up include directories (which might hard-code values). That helps both ease of use and creation of fully relocatable packages.

      Additional usage requirements such as compile options, definitions and features would be helpful, but I think the above are the most useful.




            amadio Guilherme Amadio
            bmorgan Benjamin Morgan
            2 Vote for this issue
            5 Start watching this issue


              Actual End: