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?

Your message is a bit terse, so I'm not sure if this is a suggestion that we don't need to discuss these topics further. Can you elaborate?

I don't think your email responded to any content in mine, so I'm not sure what point you're making.

My modularization effort of {fmt} was mostly done to proof what I've been talking about and teach it to interested partys.

Can you be more specific? Assuming the most recent talk is the most suitable, I assume you mean this part of this talk?

 https://youtu.be/nP8QcvPpGeM?t=1873

It's interesting, but it's not an answer to any of the questions AFAIK, because

- You don't seem to have covered installed artifacts (as I wrote in my other mail), or how such things will be packaged compared to how they are packaged today. You say that for adoption, keep the structure as is, but if you complete the work to create installed artifacts for modules I think you will need to restructure (by which I mean move code around between different files).

- You discuss gradual transition for the fmt library, but I don't think you discuss gradual transition for the consumers of the fmt library.

- I don't think you covered any issues that might come up in a broader sense in the ecosystem to transition (for example, can there be a version of fmt which a downstream can both import using 'import fmt;' and #include (as it is now without the new buildsystem requirements)). If such a version can exist then a downstream can manage the transition. If there is a version X.Y which can still be #included and a (X+1).0 which can only be imported with 'import fmt;', then an upgrade has to be done at the same time as I and all intermediate libraries change the way fmt is consumed.

- What lessons are there from py2 to py3 for example? Is it comparable at all? Many python libraries maintained "dual mode" supporting both python2 and python3 for years. Will it make sense for C++ libraries to maintain "dual mode" of headers (as they are used with current buildsystems) and "import fmt;" for years?

- You covered the need to restructure the fmt code in order to build the module, but you didn't consider the impact of all existing libraries in the C++ ecosystem having to do a similar restructuring. How can that effort be quantified?

- What is the cost of updating buildsystems to ones which can use modules? What is the ongoing maintenance cost of buildsystem code which supports modules? As far as I can see, things need to be made very explicit (at least in CMake though I don't know if that full explicitness is really needed), and that explicitness has a maintenance cost.

- Given the activation costs involved in transitioning to modules, and the ongoing maintenance costs of use of modules (and transition to modules in the ecosystems), what are the risks that we end up in a permanent transitory state? Could be negligible, I don't know, but I'd like to see reasoning for whatever the position is. I know there are potential pull-reasons to use modules such as build time, but different projects will put different value on that (such as compared to PCH).

- In general, what are the transition steps for the ecosystem? They are different to the transition steps for building (and not installing) a single library.

- Is some kind of synchronization needed for the ecosystem to transition to modules? Or does there need to be SG15 papers and books about how to do the transition?

Am I missing something or did you cover all of this in the linked talk or another one?

Or are these still important topics to discuss? Are these still unsolved problems?

I might well be over-complicating things, but in the years I've been asking these questions I haven't seen anyone thinking about them.

I think your experiment with fmt is valuable, but I do think that these topics are important. I think there's a lot more that can be done with your work on fmt as a starting point so that's encouraging.

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.

Going from C++03 to C++20+modules elides a transitionary stage, but is a migration in the form of a "thrust" something that can be expected of all libraries and their dependencies in the current C++ ecosystem?

Thanks,

Stephen.

Ciao
  Dani

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