Date: Thu, 25 May 2023 18:13:36 -0400
Em qui., 25 de mai. de 2023 às 14:54, Tom Honermann <tom_at_[hidden]>
escreveu:
> I'm not sure where the idea of a narrowing set of inputs comes from.
>
Concretely, the list of importable headers and their arguments would be in
a file that is an input to the dependency scanning. That means the
dependency file is downstream from the file with the list of importable
headers and their arguments.
Therefore if that list changes, the file has to be updated, which results
in downstream targets being invalidated.
You seem to be saying that I have another way to do that. I called it
"narrowing" because that was how I understood you were suggesting to
achieve it (i.e.: later builds have only the header units used by that unit
in that list), it seems that's not what you meant. So, let's ignore the
"narrowing" bit.
Would you mind explaining concretely a possible implementation for a build
system with the following requirements:
1. Perform the dependency scanning correctly, which depends on the list of
relevant header units and their arguments being an input to the dependency
scan.
2. Doesn't require the build system to dynamically generate new nodes on
the build graph. The full set of nodes needs to be prepared beforehand, but
edges can be added after the fact. The dependency scanning runs as part of
the build and dynamically add those edges (e.g.: CMake does this with
ninja's dyndep)
3. Doesn't require the build system to compare the output of a command to
see if it changed before deciding if a downstream target needs to be redone.
4. Has the full set of inputs and outputs known to the build system before
executing the command, and the execution may happen in an environment where
only those explicit inputs and outputs are available (e.g.: Remote
Execution API).
5. Works correctly on a clean build, and doesn't invalidate the entire
build if we change the list of header units or the arguments to existing
header units.
I honestly can't find a solution that fits all those requirements. Please
elaborate how you see that working.
Daniel
P.S.: I had originally written a response to the other points, but I think
what I wrote above is the crux of the issue, and therefore I decided to
focus only on that instead of getting into the nuances of all the other
topics that you brought up.
>
escreveu:
> I'm not sure where the idea of a narrowing set of inputs comes from.
>
Concretely, the list of importable headers and their arguments would be in
a file that is an input to the dependency scanning. That means the
dependency file is downstream from the file with the list of importable
headers and their arguments.
Therefore if that list changes, the file has to be updated, which results
in downstream targets being invalidated.
You seem to be saying that I have another way to do that. I called it
"narrowing" because that was how I understood you were suggesting to
achieve it (i.e.: later builds have only the header units used by that unit
in that list), it seems that's not what you meant. So, let's ignore the
"narrowing" bit.
Would you mind explaining concretely a possible implementation for a build
system with the following requirements:
1. Perform the dependency scanning correctly, which depends on the list of
relevant header units and their arguments being an input to the dependency
scan.
2. Doesn't require the build system to dynamically generate new nodes on
the build graph. The full set of nodes needs to be prepared beforehand, but
edges can be added after the fact. The dependency scanning runs as part of
the build and dynamically add those edges (e.g.: CMake does this with
ninja's dyndep)
3. Doesn't require the build system to compare the output of a command to
see if it changed before deciding if a downstream target needs to be redone.
4. Has the full set of inputs and outputs known to the build system before
executing the command, and the execution may happen in an environment where
only those explicit inputs and outputs are available (e.g.: Remote
Execution API).
5. Works correctly on a clean build, and doesn't invalidate the entire
build if we change the list of header units or the arguments to existing
header units.
I honestly can't find a solution that fits all those requirements. Please
elaborate how you see that working.
Daniel
P.S.: I had originally written a response to the other points, but I think
what I wrote above is the crux of the issue, and therefore I decided to
focus only on that instead of getting into the nuances of all the other
topics that you brought up.
>
Received on 2023-05-25 22:13:50