Date: Fri, 15 Oct 2021 15:45:41 -0400
On Fri, Oct 15, 2021 at 2:28 PM Gabriel Dos Reis via SG15 <
sg15_at_[hidden]> wrote:
> I would be extremely hard pressed to recommend practices that effectively
> shut down an evolution path where a given source file can have more than
> one module interface specification.
>
I don't have an answer to that, except that I think this space is already
complex enough with a 1-1 mapping from name to interface specification.
IMHO, limiting unnecessary complexity should also be a goal, so I guess I
would like to hear arguments for what is the problem that can't be solved
without that extra complexity.
> What we need is a mapping. This proposal suggests to encode that mapping
> into the host filesystem. I am skeptical that is the best practice to
> recommend in the context of C++.
>
To be clear, this proposal suggests to encode that mapping in the
filesystem in the context of distributing libraries as pre-built artifacts.
It specifically states that the internal representation inside the build
system is out of the scope of this proposal.
In fact, one of the concrete suggestions in the proposal is that the build
system should perform the discovery up-front and make that information
available in the same way the compilation database does today. The output
of that discovery process is a complete mapping of all the modules that are
relevant for this particular project -- which then the build system can
make use of in whichever way it wants.
The point of the proposal is precisely to come up with a reasonable way to
produce that mapping in the absence of a standardized package manager.
Now, it's true that the proposal *also* makes the case that *if* the
compilers support the path-based-lookup[1] a simple GNU Makefile would be
able to drive the build of a project that consumes and produces C++
modules, just by having a step that generates the mapping and then
translates it to a make dependency syntax[2].
Another reason why the path-based lookup greatly reduces the complexity of
the build system is that it's easier to avoid creating a bottleneck in the
caching ability of build systems making use of the Remote Execution API[3].
Since, realistically, the build system ends up having to assemble a map
file for each translation (either to produce the bmi or to produce a .o),
and then keep those up-to-date as modules change location. A simpler build
system would be able to just rely on the path-based-lookup and still do the
right thing.
[1] which wouldn't preclude the support for module map files, in fact I can
see a build system build a module map file for the local modules with a
fallback to path-based lookup for external libraries
[2] the accompanying code at https://github.com/bloomberg/p2473 serves as
proof-of-concept for that
[3] https://bazel.build/remote-execution-services.html
sg15_at_[hidden]> wrote:
> I would be extremely hard pressed to recommend practices that effectively
> shut down an evolution path where a given source file can have more than
> one module interface specification.
>
I don't have an answer to that, except that I think this space is already
complex enough with a 1-1 mapping from name to interface specification.
IMHO, limiting unnecessary complexity should also be a goal, so I guess I
would like to hear arguments for what is the problem that can't be solved
without that extra complexity.
> What we need is a mapping. This proposal suggests to encode that mapping
> into the host filesystem. I am skeptical that is the best practice to
> recommend in the context of C++.
>
To be clear, this proposal suggests to encode that mapping in the
filesystem in the context of distributing libraries as pre-built artifacts.
It specifically states that the internal representation inside the build
system is out of the scope of this proposal.
In fact, one of the concrete suggestions in the proposal is that the build
system should perform the discovery up-front and make that information
available in the same way the compilation database does today. The output
of that discovery process is a complete mapping of all the modules that are
relevant for this particular project -- which then the build system can
make use of in whichever way it wants.
The point of the proposal is precisely to come up with a reasonable way to
produce that mapping in the absence of a standardized package manager.
Now, it's true that the proposal *also* makes the case that *if* the
compilers support the path-based-lookup[1] a simple GNU Makefile would be
able to drive the build of a project that consumes and produces C++
modules, just by having a step that generates the mapping and then
translates it to a make dependency syntax[2].
Another reason why the path-based lookup greatly reduces the complexity of
the build system is that it's easier to avoid creating a bottleneck in the
caching ability of build systems making use of the Remote Execution API[3].
Since, realistically, the build system ends up having to assemble a map
file for each translation (either to produce the bmi or to produce a .o),
and then keep those up-to-date as modules change location. A simpler build
system would be able to just rely on the path-based-lookup and still do the
right thing.
[1] which wouldn't preclude the support for module map files, in fact I can
see a build system build a module map file for the local modules with a
fallback to path-based lookup for external libraries
[2] the accompanying code at https://github.com/bloomberg/p2473 serves as
proof-of-concept for that
[3] https://bazel.build/remote-execution-services.html
Received on 2021-10-15 14:45:55