Best practices for option naming?

I recently came across this “problem” while I restructuring our source tree. Previously our third party dependencies were in the same repository as our own code and include by hand in our own CMake files.

We changed this to pull in the third party dependencies using git submodules and adding the dependencies in our project by using ADD_SUBDIRECTORY and then including the third party target with TARGET_LINK_LIBRARIES.

The first few dependencies worked fine to include like this. Then we got stuck with dependencies that had options which the exact same name, but quite different functionality. We have managed to fix these issues in our own code.

My question is more of a best practice nature: Should options in a library be prefixed with the library name to avoid name clashes? Or is there other ways to solve this issue?

I can’t claim to be an authority on the matter, but I try to name my project-specific options and cache variables as ProjectName_VAR. I also try not to introduce options that duplicate functionality with standard variables (e.g. BUILD_SHARED_LIBS). You can make use of function scopes to change these variables before the subdirectories see them and without affecting the current directory.

Yes you should prefix cache variables with your targets/projects prefix.

This allows for the cmake-gui to also have nicer grouping, making a nice interface to the user.

This solution isn’t perfect for 100% of cases. But it handles most things.

Here is an example of 3 widely used open sourced projects that do this: