Date: Fri, 26 May 2023 08:05:06 -0400
On Fri, May 26, 2023 at 13:06:20 +0200, Mathias Stearn via SG15 wrote:
> I think basically every buildsystem currently screws this up today.
> Compilers lack a way of saying which files the current build depends on
> *NOT* existing. In theory they could be included in the deps output,
> however current build systems don't work correctly when files that don't
> exist are in there, so that isn't a viable strategy. Not saying that it is
> a _good_ thing, but we do tolerate this right now and it isn't often a
> problem in practice. I think we are mostly saved by changes of
> _has_include() also touching some other file that *is* actually included.
> That said, there is a similar problem of what to do when a new header is
> introduced earlier in the include path, and isn't detected because it
> wasn't there when the TU was built previously. This *has* bitten us a few
> times.
A concrete case (well, my analysis of the problem):
https://groups.google.com/g/ninja-build/c/O1UDnbMDbVs/m/pjlRL4nJBAAJ
--Ben
> I think basically every buildsystem currently screws this up today.
> Compilers lack a way of saying which files the current build depends on
> *NOT* existing. In theory they could be included in the deps output,
> however current build systems don't work correctly when files that don't
> exist are in there, so that isn't a viable strategy. Not saying that it is
> a _good_ thing, but we do tolerate this right now and it isn't often a
> problem in practice. I think we are mostly saved by changes of
> _has_include() also touching some other file that *is* actually included.
> That said, there is a similar problem of what to do when a new header is
> introduced earlier in the include path, and isn't detected because it
> wasn't there when the TU was built previously. This *has* bitten us a few
> times.
A concrete case (well, my analysis of the problem):
https://groups.google.com/g/ninja-build/c/O1UDnbMDbVs/m/pjlRL4nJBAAJ
--Ben
Received on 2023-05-26 12:05:09