Thought: another way of injecting behavior

Development
1

I’m aware that the modern cmake guidelines discourage projects from hard coding things like warning flags, and that these can be set from outside the project using various cmake variables.

However, it’s also best practice to avoid using variables and to propagate compiler flags using interface targets.

Therefore, in my projects I typically define some kind of Warnings target and then have something like:

option (MYLIB_DEV_BUILD "Enable developer settings" OFF)

if(MYLIB_DEV_BUILD)
    target_link_libraries (myLib PRIVATE myWarnings)
endif()

I’m wondering if it would be feasible to add a CMake variable, something to the effect of CMAKE_DEFAULT_INTERFACE_TARGET, that would specify the name of an interface target that all other targets implicitly link to. This would allow things like compiler flags to be defined in a modern cmake target-focused way, and combine this with the paradigm of injecting behavior from outside a project.

Thoughts?

2

You can already achieve that with the link_libraries() command.

3

hmm… I’ve always shied away from the directory-scoped commands, but perhaps this is one legitimate use for them…

4

What do you think about this way: GitHub - aminya/project_options: A general-purpose CMake library that provides functions that improve the CMake experience following the best practices.