As highlighted recently in another thread, there are inconsistencies in lower/uppercase and naming between generators for some of the targets that CMake automatically defines. In particular, we have all, ALL and ALL_BUILD, we have package and PACKAGE and we have test, RUN_TESTS and maybe others. It looks like Xcode and Visual Studio are the ones that have the special cases, with Makefiles and Ninja usually being consistent with each other.
I’d like to float the idea that we create a consistent set of build target names across all generators. This would make documentation and examples simpler and potentially simplify scripts that are intended to work across different generator types. We have a couple of options:
Add the missing all, package and test targets to Xcode and Visual Studio. The existing targets would also need to be retained for backward compatibility, but we should be able to create dummy targets with dependencies to forward to the canonical targets. The main downside that I can see with this strategy is that projects would end up with both targets showing in the IDE. Not sure if there’s a way to hide a target in each IDE or not.
Add special handling for the cmake --build command so that it recognises the special cases all and package and translates them into the generator-specific targets where required.
Any proposition to have a more consistent behavior across platforms is always a good idea.
The second point is a must gave.
For the first point, may be an alternate approach is to use a policy to avoid the multiplication of targets and confusion for the users. If policy is OLD, generate targets as today and for the NEW, replace targets ALL and ALL_BUILD with all and same for other divergent targets.
The reason for the inconsistent names is historical. The VS generator used upper-case and/or longer names in order to make them stand out as special when displayed in the VS IDE. There was no folder support back then. That’s also why the strange name ZERO_CHECK is used for the buildsystem check target: starting the name in Z kept the target at or near the bottom of the list.
If we do try to convert to consistent names we may need more than a policy. Command-lines in scripted environments may not have access to the policy setting and would need the automatic conversion proposed above.
I don’t think this can be policy-controlled. Policies have scope and can change throughout the project hierarchy, but these target names are global and should be consistent throughout the whole hierarchy. I guess we could take the top level policy scope for this and ignore all others, but that feels fragile.
Using top-level policy scope is fairly common practice. In this case, no other option makes sense (other than perhaps per-directory.) I think that should be OK.