So phony targets in ninja don't actually have a rule that can be executed. See: https://ninja-build.org/manual.html#_the_literal_phony_literal_rule
They are basically either: an alias or a group of targets. However, since they do have side-effects like all the dependents are ensured to be up-to-date and they can be inputs to actual build targets this means two things:
- I'm thinking phony targets are essentially
buildEnv equivalent, so they should be a natural input into our derivations
- When running
nix-ninja locally, just like how we materialize non-phony targets as a symlink, we need to walk the buildEnv of a phony target and symlink each file back into the ninja build directory to have the same "side-effect" and make it available to the user.
If we get support for phony targets, it also means our CLI can now also support multiple targets, as a virtual phony target can be generated to represent it.
So phony targets in ninja don't actually have a rule that can be executed. See: https://ninja-build.org/manual.html#_the_literal_phony_literal_rule
They are basically either: an alias or a group of targets. However, since they do have side-effects like all the dependents are ensured to be up-to-date and they can be inputs to actual build targets this means two things:
buildEnvequivalent, so they should be a natural input into our derivationsnix-ninjalocally, just like how we materialize non-phony targets as a symlink, we need to walk thebuildEnvof a phony target and symlink each file back into the ninja build directory to have the same "side-effect" and make it available to the user.If we get support for phony targets, it also means our CLI can now also support multiple targets, as a virtual phony target can be generated to represent it.