Proposal: Target property to indicate IDEs shouldn't show it
It is common for both projects and CMake itself to create targets that are needed to get things done, but are not really of direct interest to the user. The targets might be needed in order to express dependencies between operations, but the user would have no real reason to know about them or need to build them directly. An example is the step targets created by ExternalProject. Being able to tell IDEs to hide such targets might allow us to address problems like #22873 (comment 1135336). The various targets created by the CTest module for dashboard runs are arguably another (I suspect those are only really used from the command line for scripts, not likely by users from their IDEs).
I'd like to propose we support a new target property which I'll give the working name HIDDEN
. We would include the value of this property in the information written out by the file API, if the property is set. IDEs can then use that information to hide the target in their UI if the property is set to true (they might choose to have a "show hidden" option so the user can still see them if they really want to). The property would have no functional effect, it would be purely for information for IDEs, a bit like the existing FOLDER
property.
It is worth highlighting a related but different concept discussed in #22687. That issue discusses the idea of project namespaces. One of the suggestions is automatically defining namespaced aliases for targets. We might eventually want to add a target property like INTERNAL
to indicate the target is a private implementation detail of that project, so it shouldn't have the namespaced alias created. There would then be the question whether such targets should show up in an IDE. I think the user might still want to see such build targets, but I wanted to highlight this now for IDE implementors in case it affects their design for handling the feature proposed here. An IDE that allowed showing/hiding targets that are HIDDEN
might also want to offer the same support for INTERNAL
, if that ever gets implemented.