Date: Thu, 21 Apr 2022 21:05:26 -0400
On Wed, Apr 20, 2022 at 2:10 PM Nicolai Josuttis via Ext <
ext_at_[hidden]> wrote:
> Thanks Gaby and all others,
>
> I agree that this is formally nothing to discuss within the C++ standard
> committee.
>
> We see a bit the consequence of inventing on the fly instead of
> standardizing existing practice.
>
This is well within the remit of SG15 and the planned TR, though. While not
a normative standard, SG15 has been planning to supply guidance that
compilers, build systems, and package management systems can follow to
improve inter-op so we can make modules successful. We can talk about
things like file systems, search paths, compiler flags, and so on that we
have no way to, or strong agreement to, talk about in the standard itself.
An important one is a format for the compiler, or compiler supplied tool,
to communicate module dependency information. We know scanning can be done
with modern techniques much faster than in the past. Compare tools like
ripgrep with the standard grep, for example. However, we don't want to go
back to the almost accurate dependency information produced by, e.g.,
xorg's makedep. Only the compiler knows its own rules well enough to follow
what it would do.
But if we are interested in the success of modules, we should care.
> Simplicity is a key for the success of new ideas.
> So, while I agree that we need build systems in projects of significant
> size, the question is whether we still keep things as simple as possible.
> And the question is which burden we put not the build tools.
>
> IMO a compiler should parse a C++ file while a build system should not
> have to do that.
>
Compiler implementation. Possibly a separate tool, or something found by
the compiler driver. But it can't be done as a side-effect of compilation
as we do with header deps today. The directed graph has to be built before
you can schedule all the compilation, as in the worst case you could get an
out of date module interface used without being rebuilt. And that's worse
than it not being available, because it's wrong but appears to succeed.
>
>
ext_at_[hidden]> wrote:
> Thanks Gaby and all others,
>
> I agree that this is formally nothing to discuss within the C++ standard
> committee.
>
> We see a bit the consequence of inventing on the fly instead of
> standardizing existing practice.
>
This is well within the remit of SG15 and the planned TR, though. While not
a normative standard, SG15 has been planning to supply guidance that
compilers, build systems, and package management systems can follow to
improve inter-op so we can make modules successful. We can talk about
things like file systems, search paths, compiler flags, and so on that we
have no way to, or strong agreement to, talk about in the standard itself.
An important one is a format for the compiler, or compiler supplied tool,
to communicate module dependency information. We know scanning can be done
with modern techniques much faster than in the past. Compare tools like
ripgrep with the standard grep, for example. However, we don't want to go
back to the almost accurate dependency information produced by, e.g.,
xorg's makedep. Only the compiler knows its own rules well enough to follow
what it would do.
But if we are interested in the success of modules, we should care.
> Simplicity is a key for the success of new ideas.
> So, while I agree that we need build systems in projects of significant
> size, the question is whether we still keep things as simple as possible.
> And the question is which burden we put not the build tools.
>
> IMO a compiler should parse a C++ file while a build system should not
> have to do that.
>
Compiler implementation. Possibly a separate tool, or something found by
the compiler driver. But it can't be done as a side-effect of compilation
as we do with header deps today. The directed graph has to be built before
you can schedule all the compilation, as in the worst case you could get an
out of date module interface used without being rebuilt. And that's worse
than it not being available, because it's wrong but appears to succeed.
>
>
Received on 2022-04-22 01:05:29