Hey all,
would it be possible to add the ALL flag from add_custom_target for add_custom_command too? Or otherwise get the ability to manually add a dependency for the ALL pseudo target for a custom command?
The motivation comes from generation of runtime artifacts that are consumed by multiple targets, like tests or libraries or … Having to manually list these dependencies everywhere is cumbersome.
In practice, many projects just opt for using add_custom_target instead then to get the ALL dependency chain. But that has the really unfortunate side-effect of always-dirty builds. I.e. from the documentation from add_custom_target:
The target has no output file and is always considered out of date
Due to this issue, add_custom_target is even banned at work to ensure we get a ninja: no work to do. after invoking it once (and not changing anything else).
To give a concrete example for a widely used cmake snippet that causes issues in that regard: the KDE i18n framework (ab)uses add_custom_target to generate mo/ts translation files, which is a costly operation. And because it’s always dirty, this runs every time we run ninja 
See
cmake/KF6I18nMacros.cmake.in · master · Frameworks / Ki18n · GitLab and 460245 – ki18n_install(po) slows down each build, even if nothing has changed
I would love to improve that situation, but the only hack that I could think of is adding a add_custom_command for each of these add_custom_target that do the actual generation, and then keeping the add_custom_target for the ALL convenience. This would at least prevent us from wasting cycles in re-generating the translations all the time, but it would still keep the ALL target always-dirty which is still sub-optimal.
As such: Could we just get a add_custom_command(ALL) instead? Or how do other projects handle situations like this?