On 18/05/2022 17:39, Daniela Engert wrote:
> 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 mention that transition for fmt is easier because there has
already been a transition to UDLs in fmt, and similar changes have been
made for named entities with internal linkage etc. It is important to
know what the cost is. It would also be good to have a list of these
kinds of necessary transformations (which can be made prior to actually
transitioning to modules) outside of a video. It seems that there is a
lot of work to do in all C++ libraries which contain similar constructs
(plus constructs which you didn't encounter while working on fmt). That
is a cost of transitioning to modules.

- 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