Em qui., 25 de mai. de 2023 às 14:54, Tom Honermann <tom@honermann.net> 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.