The problem this commit addresses is this: Consider the following snippet:
parts:
hello-world:
plugin: dump
source:
- on amd64 to arm64: src/on-amd64-to-arm64
- on amd64 to armhf: src/on-amd64-to-armhf
... what should happen if the command toolname clean --destructive-mode is executed? Currently it breaks, because the grammar is not processed without an explict target arch (provided directly through the "--build-for" parameter or indirectly via the "--platform" one). This is at least inconvenient, and goes against the guideline we adopted for cleaning projects with multiple infos on the build-plan (accept the "wrong" config and remove the files).
There is no obvious, perfect answer here because at the stage that the grammar is currently processed we don't know yet what kind of command we are dealing with. Maybe the command needs the parts, maybe it doesn't. Possibly as a stop gap,
this commit introduces the following logic:
If build-for is provided, use that (current behavior);
If the build plan has items, use the build-for of the first one arbitrarily, just to be able to resolve and remove the grammar statements;
Otherwise, use the host arch as build-for.
This last option is risky because there's a chance it won't generate a valid parts declaration (see the new tests). That's not as bad as it looks, because either the command won't need the parts (and thus that declaration will be ignored), or it will and the lifecycle service will then generate its own error.
[ ] Have you followed the guidelines for contributing?
The problem this commit addresses is this: Consider the following snippet:
... what should happen if the command
toolname clean --destructive-modeis executed? Currently it breaks, because the grammar is not processed without an explict target arch (provided directly through the "--build-for" parameter or indirectly via the "--platform" one). This is at least inconvenient, and goes against the guideline we adopted for cleaning projects with multiple infos on the build-plan (accept the "wrong" config and remove the files).There is no obvious, perfect answer here because at the stage that the grammar is currently processed we don't know yet what kind of command we are dealing with. Maybe the command needs the parts, maybe it doesn't. Possibly as a stop gap, this commit introduces the following logic:
This last option is risky because there's a chance it won't generate a valid parts declaration (see the new tests). That's not as bad as it looks, because either the command won't need the parts (and thus that declaration will be ignored), or it will and the lifecycle service will then generate its own error.
tox?