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