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

From: John Maddock (jz.maddock_at_[hidden])
Date: 2024-07-07 10:25:16

On 07/07/2024 07:56, Daniela Engert via Boost wrote:
> Hi,
>
> what you're describing is the technique what I coined the term "dual 
> mode support" for in my presentations. I've added it to {fmt} in 2021 
> to enable the use of the library as both #include and import; MS-STL 
> adopted it for their implementation of the standard library
>
> Please take into account that I usually also add something along 
> xxx_ATTACH_TO_GLOBAL_MODULE (in this case xxx = BOOST) to avoid 
> potential ODR violations for projects that use a library either as 
> module or through headers. Otherwise users may end up with 
> conflicting, but apparently *identical* definitions that they cannot 
> decipher the reason for: one definition is attached to the named 
> module, the other to the global module. The compiler will be very 
> upset. Linkers usually work.
Sorry, don't quite follow, can you explain?
>
> Boost libraries that intend to support modules *must* also *add* tests 
> that check that the exported entities are
> Â  * available on the consumer side
> Â  * instantiation and name lookup works when called from the consumer 
> side
Absolutely.  Complete lack of build/tooling support for modules is 
currently a showstopper here.  When experimenting with a Regex module I 
basically had to resort to the command line.
>
> Module implementation units have two relevant interfaces, not one.
Also don't follow, can you explain?
> Almost all libraries that claim module capability support, and that 
> I've seen so far, fail to do that. In rare cases I have forks that add 
> this missing piece.
> Lacking those gives users horrible experiences and modules a bad 
> reputation.
>
> On the standard library: *all* C++ implementers of the standard 
> library have agreed to support C++20 modules also for C++20 build 
> modes. So you're not tied to C++23.
Good.  But if the module uses "import std;" and something somewhere else 
#includes <iostream> my experience is that everything breaks.  It's not 
supposed to, but it does.  I must test the latest MSVC release though.
>
> And lastly, there is BMI compatibility and the story of compiler flags 
> matching. But that's for a different day.

Right, there is no possibility of a build-and-install step, each project 
must build the modules they are using from source using options that 
exactly match their project.  It's not hard, but it is a barrier to 
adoption.

John.