I think it would be an improvement to CMake if projects were considered “objects” in the same way as targets and directories – basically meaning you could set/retrieve properties on projects.
I also think this would help with encapsulation/modularization in the spirit of modern cmake – for example, I would love to someday replace
set (CMAKE_CXX_STANDARD 20)
with:
set_project_properties (myProject PROPERTIES CMAKE_CXX_STANDARD 20)
Any thoughts on this?
I don’t know if I see much utility in this. I don’t know what kinds of properties I would attach to an exported project that isn’t better as a local variable anyways (version, ABI, prefix, etc.). Within a project, I don’t see this being any better than (namespaced) global properties (as they appear just as difficult to query) or scoped variables. Do you have other use cases for such an object type?
I think the main use case for this would be to allow increased modularity. As it stands today, if I’m building a CMake project as a subproject, and this CMake project sets any global CMAKE_ variables, it’s a bit unclear whether those settings affect the superproject. If projects themselves had properties, then every cmake project could configure “project-global” settings as project properties, which would be contained to that project’s targets, and could be queried from any containing superprojects.
This is why I patch vendored libraries: to make sure they aren’t messing with the cache beyond what makes sense for a vendored project to do. The newer cache-related policies help with this, but it is still “too new”.
I’ll also note that this means that any target properties that depend on the project properties must wait until generate time to have their real value pinned down (as the project may change later). I think figuring out how to export this information is something to consider.
If one wants this kind of control, I find the project-local INTERFACE library that drags all of this stuff around works just fine.
Bumping this old thread.
I think that having projects as first-class entities would be helpful for implementing a number of package-management features.
For example, a project could declare public and private dependencies, and then CMakePackageConfigHelpers could use this information when configuring the <project>-config.cmake file, so that project authors don’t have to duplicate the dependency information in multiple files.
I believe there was recent work on exporting find_package calls.