On Sat, Jun 12, 2021, 15:31 David Blaikie <dblaikie_at_[hidden]> wrote:

> Really appreciate the write up!
>

Thanks!

* The terms "source to source" and "source to binary" seem a bit confusing
> to me
>

Yes, it is really hard to communicate the whole concept with a few words,
I'll think more about this terminology and see how to make that more clear.

* Cheap Module Discoverability: The second paragraph maybe could benefit
> from a few more words [...] at least to my knowledge there's either a full
> pre-scan to discover the dependencies
>

Yes, but you would be scanning files that you are expecting to build
anyway.

However, when you have unrelated modules files available in the system,
you'd need to read all of them, just to throw it away because they were not
actually going to be used by your build.

In other words, each libfoo-dev you install in your Debian system would
make the build more expensive.

>
* Cheap Module Discoverability R2: [...] You're suggesting "within the
> scope of ABI uniformity" - so one set of configs for all the unixy, itanium
> compilers that already try to be command line compatible, another set for,
> say MSVC+clang-cl, etc.
>

Right, since we're trying to focus on requirements, I can't really say the
need goes beyond that.

However, my engineering brain would very much appreciate if the
interoperability became universal.

* Dependency Graph of Modules External to the Build: [...] My
> understanding is the spec was designed to make this cheap - to ensure that
> not a lot of C++ parsing complexity would be required to read the start of
> a module to discovery its dependencies. Do you find this not to be the
> case, or to be inadequate for practical purposes?
>

I'll review that part of the spec one more time, and either expand or
remove the section.

* Compiler-indepnedent module parsing: [...] though I think my generally
> understanding has been that this would still be viable, but these BMI
> artefacts would be local build product in some build-specific cache
> directory.
>

Exactly, which works well for "source to source" builds, however how would
libblabla-dev on a Debian system provide it when the BMI is not
interoperable even on different minor versions of the same compiler?

a module may need particular flags to be compiled correctly and those flags
> may differ from those used to build the consumer of the module (I'm not
> 100% sure that supporting this situation is necessary
>

In "source to source" builds this happens naturally, because CMake would
know that this module belongs to this target, and therefore would know to
do the module parsing in the context of that target.

In "source to binary" we don't have the context of how that module is meant
to be parsed, we only have the context for this particular translation unit.

* Cheap Parsing of Modules External to the Build: [...] but this is talking
> about a feature of both the output format of the compiler (BMI) and also
> about where these output files are stored/accessed/how they can be
> concurrently generated, I take it? So that they could be shared between
> different builds happening on the same machine?
>

Correct, I think it's reasonable to have an "as optimized as possible"
representation for the context of the current build. What I'm advocating
for is an additional format that provides a middle ground between the BMI
and having to do a complete parse. One example could be having the module
file completely preprocessed already.