Date: Thu, 13 Oct 2022 23:04:05 +0000
> - generated source files
For generated source files, how is the problem different from importing a named module being imported?
For non-generated source files, would it be conceivable to run the dependency scanning just before generating the build definition?
> changing a source file
Only if the change happens after the generation of the build definition (e.g. "inner loop"), but the gate to that is the timestamp of the build definition generation. And this is similar to the generated source file scenario, which in my understanding affects also importation of named modules. No?
-- Gaby
-----Original Message-----
From: Ben Boeckel <ben.boeckel_at_[hidden]>
Sent: Thursday, October 13, 2022 2:17 PM
To: Gabriel Dos Reis <gdr_at_microsoft.com>
Cc: sg15_at_[hidden]
Subject: Re: [SG15] Header units again.
On Thu, Oct 13, 2022 at 19:37:40 +0000, Gabriel Dos Reis wrote:
> > Yes, but we can't then add a rule to `build.ninja` to say "hey, make a
> > BMI of this header file no one knew about until we started building
> > stuff".
>
> I suppose that raises the question: at what point do you run the
> dependency scanner? During build?
Yes, it has to be run during the build. Consider the following cases:
- generated source files
Source files which are built during the build by tools built during the
build cannot exist when CMake runs the first time. Doing some kind of
"phased generation" adds in a new build graph to consider for each phase
when considering "is this robust?".
Even if we did scan files that exist now and wait on those that will be
generated later, we cannot say "module X doesn't exist" until we scan
all of those generated sources to know that it doesn't come from there.
- changing a source file
With pre-scanning, changing a source file would require rerunning CMake
and regenerating the build scripts on any source file that *might*
import or export a module to update the graph in case its module
dependencies change. This is not something a discrete build system can
support (a continuous build tool might theoretically be able to adapt to
source changes and build the in-memory graph up again though I worry
about behaviors of invalid syntax, partial writes, etc. in these cases).
--Ben
For generated source files, how is the problem different from importing a named module being imported?
For non-generated source files, would it be conceivable to run the dependency scanning just before generating the build definition?
> changing a source file
Only if the change happens after the generation of the build definition (e.g. "inner loop"), but the gate to that is the timestamp of the build definition generation. And this is similar to the generated source file scenario, which in my understanding affects also importation of named modules. No?
-- Gaby
-----Original Message-----
From: Ben Boeckel <ben.boeckel_at_[hidden]>
Sent: Thursday, October 13, 2022 2:17 PM
To: Gabriel Dos Reis <gdr_at_microsoft.com>
Cc: sg15_at_[hidden]
Subject: Re: [SG15] Header units again.
On Thu, Oct 13, 2022 at 19:37:40 +0000, Gabriel Dos Reis wrote:
> > Yes, but we can't then add a rule to `build.ninja` to say "hey, make a
> > BMI of this header file no one knew about until we started building
> > stuff".
>
> I suppose that raises the question: at what point do you run the
> dependency scanner? During build?
Yes, it has to be run during the build. Consider the following cases:
- generated source files
Source files which are built during the build by tools built during the
build cannot exist when CMake runs the first time. Doing some kind of
"phased generation" adds in a new build graph to consider for each phase
when considering "is this robust?".
Even if we did scan files that exist now and wait on those that will be
generated later, we cannot say "module X doesn't exist" until we scan
all of those generated sources to know that it doesn't come from there.
- changing a source file
With pre-scanning, changing a source file would require rerunning CMake
and regenerating the build scripts on any source file that *might*
import or export a module to update the graph in case its module
dependencies change. This is not something a discrete build system can
support (a continuous build tool might theoretically be able to adapt to
source changes and build the in-memory graph up again though I worry
about behaviors of invalid syntax, partial writes, etc. in these cases).
--Ben
Received on 2022-10-13 23:04:08