# Inconsistencies in case sensitivity and naming of CMake-created build targets
**URL:** https://discourse.cmake.org/t/inconsistencies-in-case-sensitivity-and-naming-of-cmake-created-build-targets/627
**Category:** Development
**Created:** [February 13, 2020, 12:20am UTC](https://discourse.cmake.org/t/inconsistencies-in-case-sensitivity-and-naming-of-cmake-created-build-targets/627 "2020-02-13T00:20:10Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [February 13, 2020, 12:20am UTC](https://discourse.cmake.org/t/inconsistencies-in-case-sensitivity-and-naming-of-cmake-created-build-targets/627/1 "2020-02-13T00:20:10Z")
As highlighted recently in [another thread](https://discourse.cmake.org/t/targets-package-and-source-package-created-only-when-configured-for-make-or-ninja/620/2), 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.
What do people think? Is this worth exploring?
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [February 13, 2020, 9:47am UTC](https://discourse.cmake.org/t/inconsistencies-in-case-sensitivity-and-naming-of-cmake-created-build-targets/627/2 "2020-02-13T09:47:37Z")
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.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [February 13, 2020, 1:53pm UTC](https://discourse.cmake.org/t/inconsistencies-in-case-sensitivity-and-naming-of-cmake-created-build-targets/627/3 "2020-02-13T13:53:28Z")
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.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [February 13, 2020, 8:39pm UTC](https://discourse.cmake.org/t/inconsistencies-in-case-sensitivity-and-naming-of-cmake-created-build-targets/627/4 "2020-02-13T20:39:49Z")
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.
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [February 13, 2020, 8:42pm UTC](https://discourse.cmake.org/t/inconsistencies-in-case-sensitivity-and-naming-of-cmake-created-build-targets/627/5 "2020-02-13T20:42:10Z")
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.