Re: [config] First steps towards C++20 modules

From: Boris Kolpackov (boris_at_[hidden])
Date: 2024-08-08 06:11:52

Thanks for the insight. Some comments/questions below.

Daniela Engert <dani_at_[hidden]> writes:

> Does Microsoft's STL implementation count as "substantial"?

I assumed they use the export-using approach, but you are right,
they include the standard library headers in the module purview.
Though they don't wrap them in one extern "C++" block but rather
modified each header to explicitly `export extern "C++"` each name
(via the _EXPORT_STD macro). So it's not quite the same -- they
have a lot more precision over what ends up with extern "C++"
(as well as what gets exported).

> BTW: do you know of *any* substantial non-STL codebase that uses modules in
> any meaningful way? Besides Microsoft Office, of course.

My go-to test is the async_simple project that was converted to modules
by Chuanqi Xu:

https://github.com/alibaba/async_simple/tree/CXX20Modules/

I added build2 support and successfully built it using the standard
library modules with Clang/libc++. That work is here:

https://github.com/boris-kolpackov/async_simple/tree/CXX20Modules-build2

Other than that, I am aware of a couple of build2 users that are
using modules (including import std) in green-field projects, but
those are not public.

> We do in our company. We use a mixture of headers, pure modules (made from
> scratch), modules with headers wrapped by 'extern "C++"' like you mention,
> modules with headers exporting (parts) of their interface by exported
> using-declarations, and combinations of that, in the codebase driving a huge
> machine that is developed since 2021 and has precursors (i.e. builds from
> code) starting from 2007. 3rd-party libraries (usually modules wrapping
> headers) are part of that. This codebase is in the 1M LOC range.

That's encouraging, thanks for sharing. Is this MSVC-only or do you
also build with Clang?

> > Feels like there bound to be gotchas.
> 
> Right: [...]

Another thing I am fuzzy about that I forgot to mention is the
implementation unit. Feel like the most sensible way is to build
it off the header (rather than the module). The module interface
also produces an object file. Are there no issues combining these
two object files in the same build (duplicate symbols, etc)?