Date: Fri, 15 Oct 2021 17:50:44 -0400
On Fri, Oct 15, 2021 at 5:00 PM Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> I am thinking, indeed, of a subset of the facilities in the Clang’s
> modulemap experiment: a mapping from a module name to where to find the
> corresponding BMI – no filesystrem poking adventure to discover something.
> It wouldn’t shut down the door to possible multiple module interface stored
> in the same file. I am unsure of why that is considered “extra complexity”.
>
Ok. It doesn't seem like we're talking about the same thing at all. I'll
ask for you to please consider taking a new read at both papers, because
the point you're trying to make is unrelated to the thing being discussed.
The question is not whether or not a map file is a good or a bad way to map
from a module name to a bmi file. That's irrelevant to the discussion.
Let me try to formulate a few simple questions that should reframe the
conversation in terms of the actual problem that the papers try to address.
1) Organization A is trying to ship a C++ library that contains modules,
how does it advertise which modules the library has? Which files contain
the interfaces? How is a compiler supposed to parse those interfaces? Which
modules do they depend on? And maybe even, as an optimization, How to ship
the BMI file for the compiler the library vendor used (just in case the
consumer is using the same compiler)?
2) Organization B is trying to consume modules from various libraries that
are shipped to them as prebuilt artifacts. How is it supposed to know how
to find the mappings? or, in case they use a different compiler version,
how to produce their own BMI file for those modules?
3) Organization C is trying to run static analysis on code from
organization B that consumes library modules from organization A. How is it
that it finds out how to reproduce the parsing context for all the modules
required to correctly parse the actual translation units? Especially
considering the static analysis tool is not deeply integrated into the
build system, and it only observes the build system via artifacts like the
compilation database?
Those are the questions the proposal is trying to answer.
> I am thinking, indeed, of a subset of the facilities in the Clang’s
> modulemap experiment: a mapping from a module name to where to find the
> corresponding BMI – no filesystrem poking adventure to discover something.
> It wouldn’t shut down the door to possible multiple module interface stored
> in the same file. I am unsure of why that is considered “extra complexity”.
>
Ok. It doesn't seem like we're talking about the same thing at all. I'll
ask for you to please consider taking a new read at both papers, because
the point you're trying to make is unrelated to the thing being discussed.
The question is not whether or not a map file is a good or a bad way to map
from a module name to a bmi file. That's irrelevant to the discussion.
Let me try to formulate a few simple questions that should reframe the
conversation in terms of the actual problem that the papers try to address.
1) Organization A is trying to ship a C++ library that contains modules,
how does it advertise which modules the library has? Which files contain
the interfaces? How is a compiler supposed to parse those interfaces? Which
modules do they depend on? And maybe even, as an optimization, How to ship
the BMI file for the compiler the library vendor used (just in case the
consumer is using the same compiler)?
2) Organization B is trying to consume modules from various libraries that
are shipped to them as prebuilt artifacts. How is it supposed to know how
to find the mappings? or, in case they use a different compiler version,
how to produce their own BMI file for those modules?
3) Organization C is trying to run static analysis on code from
organization B that consumes library modules from organization A. How is it
that it finds out how to reproduce the parsing context for all the modules
required to correctly parse the actual translation units? Especially
considering the static analysis tool is not deeply integrated into the
build system, and it only observes the build system via artifacts like the
compilation database?
Those are the questions the proposal is trying to answer.
Received on 2021-10-15 16:50:57