Am 18.05.2022 um 17:34 schrieb Stephen Kelly via SG15:
>
> On 18/05/2022 13:42, Daniel Ruoso wrote:
>>
>
> Indeed. That's one of the things I wonder about (and wrote here about
> 5 years ago). There is a lot more which I think is important and which
> still isn't being thought about even now AFAICT.
>
> [for example
>
> - how will transition to modules work?
>
> - Will large parts of libraries have to be restructured? It's still
> not clear to me how any module can be used, but for example it looks
> like maybe parts of fmt.cc could be split and installed so that
> downstreams could generate the modules from the headers.
>
> - Will it be possible to support both modules of some kind and headers
> for a library in a transitionary phase? Note that this means without
> the new buildsystem requirements brought in by an attempt to use
> modules - meaning #includes containing imports are no-go. That might
> be possible by splitting fmt.cc, but will that approach scale? Will
> all libraries need to do similar code restructuring for (real) modules
> support?
>
> - How much danger is there of bifucating the ecosystem between
> projects that migrate to modules and those that don't? What could make
> that more or less likely?
>
> This is all independent of CMake. I don't know if anyone has put any
> thought into those topics. Hopefully someone will do so at some point.
>
> ]
>
Have you seen my talks on these topics from the past 3 years or so? My
modularization effort of {fmt} was mostly done to proof what I've been
talking about and teach it to interested partys.

At present I'm applying all of my gathered knowlege to an old project
that's been revived and thrust from C++03 to C++20 with an all-modules
approach.

Ciao
   Dani

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5