C++ Logo

sg15

Advanced search

Re: [Tooling] [Ext] Modules and tooling: Resolving module import declarations

From: Tom Honermann <tom_at_[hidden]>
Date: Sun, 2 Sep 2018 11:16:25 -0400
On 09/02/2018 10:01 AM, Nathan Sidwell wrote:
> On 09/02/2018 12:07 AM, Tom Honermann wrote:
>
>> Gcc
>> $ gcc -Ifoo/include t.cpp -lfoo -o t
>> $ gcc -fmodules-ts -c Ifoo/include foo.cpp # generates foo.nms
>> (and unused foo.o)
> [missed '-' on the I option there, but that's obvious]

Oops.

>
> foo.o is not unused in general, it contains things like the
> definitions of exported or module-linkage non-inline functions &
> variables.

Indeed. In the example, it is unused because it was presumably compiled
previously and linked into the 'foo' library.

The example is meant to reflect the scenario where a project (t.cpp)
uses a packaged component (foo). Assuming that module artifact formats
remain non-portable across compilers and non-stable across compiler
releases, it doesn't make sense for a package manager to install module
artifacts. Consumers of the component therefore need to be able to
generate the module artifact, but need not generate and use the
corresponding object file directly if it is already available in a
library to be linked in. This demonstrates the utility in supporting a
compiler invocation interface that generates only the module artifact
(which I believe only Clang supports today; I missed adding "and unused
foo.obj" for the Microsoft example).

> IIUC clang treats the module BMI as an additional stage of compilation:
> x.cpp->x.pcm->x.o
> which must be compiled down to an object for correctness.

That matches my understanding.

Tom.

Received on 2018-09-02 17:16:29