Feature Request: Set default options and namespace entry in add_subdirectory

Development
1

As per this stackoverflow answer, it looks like subproject options may be global to the project itself. If that’s the case, then it is possible that a project with a number of subprojects may have option collisions.

If the above is indeed an issue, then may I suggest two additions to the add_subdirectory command.

The first is to be able to specify multi-value default options in the add_subdirectory command, for example as follows:

add_subdirectory(thirdparty/libsndfile
	DEFAULT_OPTIONS
	ENABLE_EXTERNAL_LIBS=OFF
	ENABLE_MPEG=OFF
	BUILD_TESTING=OFF
	BUILD_PROGRAMS=OFF
	BUILD_EXAMPLES=OFF
	ENABLE_CPACK=OFF
	ENABLE_BOW_DOCS=OFF
	ENABLE_PACKAGE_CONFIG=OFF
	INSTALL_PKGCONFIG_MODULE=OFF
)

The second suggestion is to add a single-value namespace option in add_subdirectory, so extending the above example:

add_subdirectory(thirdparty/libsndfile
	NAMESPACE SF
	DEFAULT_OPTIONS
	ENABLE_EXTERNAL_LIBS=OFF
	ENABLE_MPEG=OFF
	BUILD_TESTING=OFF
	BUILD_PROGRAMS=OFF
	BUILD_EXAMPLES=OFF
	ENABLE_CPACK=OFF
	ENABLE_BOW_DOCS=OFF
	ENABLE_PACKAGE_CONFIG=OFF
	INSTALL_PKGCONFIG_MODULE=OFF
)

If the above is implemented, then one could possibly specify an option at the configuration stage as follows: cmake .. -DSF::BUILD_TESTING=ON

2

You may be interested in the following proposal for project-level namespaces: https://gitlab.kitware.com/cmake/cmake/-/issues/22687

3

Thanks for referencing the relevant issue which I missed somehow.

Clément Grégoire wrote

Have project() set the namespace to PROJECT_NAME by default, but allow to override it using project( NAMESPACE )

I agree that having NAMESPACE default to PROJECT_NAME as per above makes sense, however, the NAMESPACE part of the proposal relies on the cmake file author to specify a NAMESPACE to be set in the project(). If it isn’t provided then one may be stuck with a possibly more verbose PROJECT_NAME as the NAMESPACE

Eyal Rozenberg wrote

While this discussion has focused on the namespace’ing of targets, I would like to draw people’s attention also to the question of cached options, which, coming from different subprojects/subdirectories, may also clash. See #23568 where I brought this up in the context of FetchContent.
It may be relevant/appropriate to have project namespaces cover cached project-CMakeLists-originating options as well, or some of them.

Happy this was brought up in the issue, I completely agree :slightly_smiling_face:

Good luck with the implementation!