Re: On Boost and modules

From: Boris Kolpackov (boris_at_[hidden])
Date: 2024-04-09 14:33:02

Andrey Semashev via Boost <boost_at_[hidden]> writes:
 
> It doesn't make sense to have to build the whole Boost into a module
> only to pull a small part from it. I would much rather include the
> headers I want instead.

I actually don't think having a single/only `boost` module would be
the right way to modularize Boost. I would suggest having a module
per library (at least; maybe even more granular, say for Spirit,
which is actually three libraries in one). And a single `boost`
module that re-exports them all. Users who want all of Boost, can
import `boost`, those like you who want to carefully manage their
dependencies can import more granular modules. And, at least in
build2, we only build BMIs that are actually used (imported).

(This brings an interesting question: if I import `boost`, but only
use a small subset of libraries, how do I know which ones I should
be linking. Trial and error until there are no more unresolved symbols
feels a bit stone age.)

> One other thing that isn't clear is how modules interact with compiled
> libraries. I don't suppose modules will replace static/shared libraries,
> so I presume a module will be added on top of the library?

Yes, from the library perspective, module interfaces are pretty similar
to headers: when building the library, the object files produced when
compiling module interfaces are linked into the library along with other
TU object files. The interfaces are shipped/installed with the library
and then compiled by the library consumers.

> How should it "export" the symbols that are already exported from the
> compiled library then?

Modules actually make authoring portable shared libraries almost sane.
Specifically, with modules, you only need the dllexport part of the
dllexport/dllimport dance (and yes, this works for variables, not only
functions). That is, you need to compile the BMI for a shared library
with dllexport and then, when this BMI is used in import, dllimport
happens auto-magically.

Which means that this can all be taken care of by the build system
without you having to provide the export header (or equivalent) that
arranges for the dllexport/dllimport dance. For example, in build2
we have implemented the __symexport keyword-like macro (defined
automatically by the build system) which you use like so:

export namespace n
{
  __symexport void f ();

  class __symexport C
  {
    ...
  };
}

(At first it seems bizarre that you have to ask to export things
twice. But if you meditate on this a bit and also consider that
module export deals with C++ names while symbol export deals with
symbols, and the mapping is by no means one-to-one, you will likely
conclude that this double-export approach is probably for the best.)