Date: Wed, 24 May 2023 14:48:12 -0400
Em qua., 24 de mai. de 2023 às 11:06, Tom Honermann <tom_at_[hidden]>
escreveu:
> Concretely, what would happen is that if I do an `apt-get update &&
> apt-get dist-upgrade` it could result in a full clean build in my
> incremental build because the list of importable headers or the
> arguments to those could change.
>
> We seem to have a clear disagreement regarding this.
>
Yes. That much is true.
Let me try to break it down in steps, so we identify where the disagreement
is:
1. The list of header units and their arguments (at least the ones used in
that translation unit) are an input to the dependency scanning process.
2. The dependency file is used to generate the module map.
3. The module map is an input to the translation itself.
4. For a significant number of build systems, an invalidation on the
beginning of a chain unconditionally invalidates all downstream targets.
So far so good? Now, let's start with the clean build.
6. We don't yet know which importable headers could be possibly used by
any translation unit, we just have a clean checkout of the code and
libraries installed on the system.
7. The example I presented elsewhere on this thread hopefully shows that
the dependency scanning needs to know the list of importable headers before
the dependency scanning starts.
8. Therefore, the only option is to give the entire list of importable
headers and their arguments to the initial dependency scanning.
In other words, your proposal presumes that the dependency chain that
started from the clean build somehow gets replaced by a narrower set of
inputs. I don't see how that would work in ninja, for instance.
Would you mind elaborating how you see that happening?
daniel
escreveu:
> Concretely, what would happen is that if I do an `apt-get update &&
> apt-get dist-upgrade` it could result in a full clean build in my
> incremental build because the list of importable headers or the
> arguments to those could change.
>
> We seem to have a clear disagreement regarding this.
>
Yes. That much is true.
Let me try to break it down in steps, so we identify where the disagreement
is:
1. The list of header units and their arguments (at least the ones used in
that translation unit) are an input to the dependency scanning process.
2. The dependency file is used to generate the module map.
3. The module map is an input to the translation itself.
4. For a significant number of build systems, an invalidation on the
beginning of a chain unconditionally invalidates all downstream targets.
So far so good? Now, let's start with the clean build.
6. We don't yet know which importable headers could be possibly used by
any translation unit, we just have a clean checkout of the code and
libraries installed on the system.
7. The example I presented elsewhere on this thread hopefully shows that
the dependency scanning needs to know the list of importable headers before
the dependency scanning starts.
8. Therefore, the only option is to give the entire list of importable
headers and their arguments to the initial dependency scanning.
In other words, your proposal presumes that the dependency chain that
started from the clean build somehow gets replaced by a narrower set of
inputs. I don't see how that would work in ninja, for instance.
Would you mind elaborating how you see that happening?
daniel
Received on 2023-05-24 18:48:26