Namespacing#

Until proper namespacing can be automatically implemented [1], there are a few standards that the wider community have converged upon. These standards are designed so that the project is transparently imported via find_package and FetchContent.

Options#

The project options should be prefixed by <PROJECT>_, where <PROJECT> is the uppercase name of the project.

The option’s help text should also be prefixed by <Project>: to indicate the source of the option’s definition. This is useful when an importing project overrides or forces an imported project’s option, i.e.:

project(ProjectA)
option(PROJECTB_TESTS "ProjectA: Overload" ON)
FetchContent_Declare(ProjectB
        ...
)

Targets#

Both the actual target names and the aliases should be prefixed by the <Project> namespace:

add_library(Project_Hello)
add_library(Project::Hello ALIAS Project_Hello)
set_target_properties(Project_Hello PROPERTIES
        OUTPUT_NAME hello
        EXPORT_NAME Hello
)

Note

Here we are setting OUTPUT_NAME and EXPORT_NAME to properly set the target’s file name and exported name.

Variables#

Generally, we don’t need to worry about the namespacing of variables since these are not propagated outwards. However, this means that we have to explicitly export the variables we want to export. The variables we want to export are <Project>_VERSION and all variables exported in <Project>Config.cmake.

Message#

For namespacing messages, you should push a relevant namespace on the CMAKE_MESSAGE_CONTEXT stack. Just make sure to pop the namespace to sections that are in a macro or include.