On Fri, Sep 3, 2021 at 1:28 PM Peter Dimov via Ext <ext_at_[hidden]>
wrote:

> Ville Voutilainen wrote:
> > On Fri, 3 Sept 2021 at 20:12, Peter Dimov via Ext <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.