On Fri, Sep 3, 2021 at 1:28 PM Peter Dimov via Ext <ext@lists.isocpp.org> wrote:
Ville Voutilainen wrote:
> On Fri, 3 Sept 2021 at 20:12, Peter Dimov via Ext <ext@lists.isocpp.org>
> 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.