Date: Wed, 30 Oct 2024 12:44:01 -0400
Remember that there are lots of existing ways for tools to produce files
that can't be built correctly, what was important about modules is that the
design broke current best practices for make, and to a lesser extent ninja,
based builds in order to describe the necessary dependencies and the
structure of a project for the correct ordering of a successful build, even
for a clean, full, build. Build systems needed cooperation from
the compiler in a pre-build step to understand what their true
dependencies are, and to order the build correctly. They always, of course,
needed some help from the compiler to be completely accurate, but the
description of dependency could be produced as a side-effect of
compilation, and would not affect the shape of the graph.
Producing a file with a timestamp in the name that might as well be a
random number has always been possible, but in general does not make it out
of a developers sandbox.
Producing a header file to be used is more complicated, of course, as are
tools that generate files that are, while predictable for a given input,
are dependent on that input. We use such a tool that generates components
for a message schema where the types in the schema may govern the output
file name. Some IDL compilers behave similarly. However, as long as the
files are stable for a given input, a build system generator ought to be
able to do a scan step similar to module interfaces, and then construct the
graph.
If the outputs are unpredictable, the situation is in general hopeless, but
also a localized problem?
On Wed, Oct 30, 2024 at 9:30 AM Boris Kolpackov via SG15 <
sg15_at_[hidden]> wrote:
> Gabriel Dos Reis <gdr_at_[hidden]> writes:
>
> > For modules, the compiler is able to report dependencies. Do we
> > have analogous situation here?
>
> It needs to be. Specifically, additional inputs and outputs should
> be reportable ahead of compilation and preferably this should be
> relatively cheap. It needs to be ahead of compilation because inputs
> themselves could be auto-generated. And I am not aware of any build
> system that doesn't require dynamic outputs to be known before invoking
> the tool (build2 certainly doesn't support this and likely never will).
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
that can't be built correctly, what was important about modules is that the
design broke current best practices for make, and to a lesser extent ninja,
based builds in order to describe the necessary dependencies and the
structure of a project for the correct ordering of a successful build, even
for a clean, full, build. Build systems needed cooperation from
the compiler in a pre-build step to understand what their true
dependencies are, and to order the build correctly. They always, of course,
needed some help from the compiler to be completely accurate, but the
description of dependency could be produced as a side-effect of
compilation, and would not affect the shape of the graph.
Producing a file with a timestamp in the name that might as well be a
random number has always been possible, but in general does not make it out
of a developers sandbox.
Producing a header file to be used is more complicated, of course, as are
tools that generate files that are, while predictable for a given input,
are dependent on that input. We use such a tool that generates components
for a message schema where the types in the schema may govern the output
file name. Some IDL compilers behave similarly. However, as long as the
files are stable for a given input, a build system generator ought to be
able to do a scan step similar to module interfaces, and then construct the
graph.
If the outputs are unpredictable, the situation is in general hopeless, but
also a localized problem?
On Wed, Oct 30, 2024 at 9:30 AM Boris Kolpackov via SG15 <
sg15_at_[hidden]> wrote:
> Gabriel Dos Reis <gdr_at_[hidden]> writes:
>
> > For modules, the compiler is able to report dependencies. Do we
> > have analogous situation here?
>
> It needs to be. Specifically, additional inputs and outputs should
> be reportable ahead of compilation and preferably this should be
> relatively cheap. It needs to be ahead of compilation because inputs
> themselves could be auto-generated. And I am not aware of any build
> system that doesn't require dynamic outputs to be known before invoking
> the tool (build2 certainly doesn't support this and likely never will).
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2024-10-30 16:44:15