* x.cppm when compiled will produce {modulename}.bmi and x.o. At least gcc does.

MSVC, since the Modules TS era, produces an IFC and OBJ file when it compiles an interface file unit in its default mode. You can also tell the compiler to produce only an IFC with the ‘/ifcOnly’ flag (say you’re doing just IDE/Design Time analysis).


  * The unlinking of module name and filename is near the heart of the build system problem.

I’ve found this to actually not be the problem, and a great tool for moving the filesystem complexity out of the source code and put it squarely in the build definition where it belongs. It means one can easily relocate sources and build artefact without worrying about the (file) container’s name.
For example, imagine the scenario where Modules codes is generated automatically (say at build time or runtime and dynamically loaded or linked), dissociating the module name from the filename of the file containers means you can separate concerns and not dump the complexity of the filesystem (e.g. for obfuscation/security/race condition prevention purposes) into the generated code.

-- Gaby

From: Ext <ext-bounces_at_[hidden]> On Behalf Of Steve Downey via Ext
Sent: Friday, September 3, 2021 10:33 AM
To: Evolution Working Group mailing list <ext_at_[hidden]>; ISO C++ Tooling Study Group <sg15_at_[hidden]>
Cc: Steve Downey <sdowney_at_[hidden]>
Subject: Re: [isocpp-ext] Suffixes for module files



On Fri, Sep 3, 2021 at 1:28 PM Peter Dimov via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
Ville Voutilainen wrote:
> On Fri, 3 Sept 2021 at 20:12, Peter Dimov via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>>
> wrote:
> >
> > Ville Voutilainen wrote:
> > > How? All this is no different from building a binary library, where
> > > the source codes produce a consumable build artifact for
> > > other programs. You build that from C++ source. You build a module
> > > from C++ source. None of those reasons
> > > suggest to me in any way that I couldn't just use .cpp.
> >
> > The difference is that (a) compiling x.cppm produces both x.o and x.bmi
> > and (b) to compile y.cpp you need x.bmi, which is a dependency that
> > does not exist between old-school x.cpp and y.cpp.
>
> Building foo*.cpp produces a libfoo.so and a foo.h, to use libfoo, you
> need to include foo.h
> and link to libfoo.so.
> Building mymodule*.cpp produces a mymodule.o and a mymodule.bmi that I
> both need
> to use MyModule. The fundamental difference suggested is not there.

The build systems today know that compiling x.cpp only produces x.o and
not an artefact like x.h that's required to compile y.cpp. When they see x.cppm,
they will know that compiling it produces an artefact x.bmi, in addition to x.o.

Of course, it's possible to make them scan the source instead.

x.cppm when compiled will produce {modulename}.bmi and x.o. At least gcc does. The unlinking of module name and filename is near the heart of the build system problem.