On Thu, Feb 3, 2022 at 7:23 PM Olga Arkhipova via SG15 <
sg15_at_[hidden]> wrote:

> On the last meeting I promised to write down my comments on
> https://wg21.link/p2473r1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2Fp2473r1&data=04%7C01%7Colgaark%40microsoft.com%7C3841d36abfe94a46dd0208d9e5dd4e6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637793560958196832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Zpx5mdvbK5%2FKXkxDz%2FXG6iUsyFe5lk1upVKfsoPAeec%3D&reserved=0> -
> Distributing C++ Module Libraries
>
>
>
> My main concern is that any requirement to have file names and locations
> to match the module name defined in the c++ code inevitably adds more work
> for the user in code maintenance. It also affects many IDE scenarios, such
> as code refactoring. Even for sophisticated build systems like msbuild it
> will be hard to provide much aid to the users in creation and automatic
> maintenance of the proposed folder/file structures according to the
> changing module names in the code.
>
>
>
> An argument was made in the previous discussions that the proposed
> structure would only be required for prebuilt libraries, affecting only the
> packaging of those libraries, but not the user.
>
>
>
> But if this folder structure is used only for prebuilt modules and not
> modules in the user code it adds the complexity for all tools that need to
> rebuild all modules as they would needs to use different ways to do it for
> user or prebuilt modules. The library authors will also need to either
> spend time manually creating those structures for their packages or find a
> not so trivial way to create them automatically. Again, the existing
> tooling will not be able to provide much help there.
>
>
>
> I’ve just submitted https://wg21.link//P2536R0 <https://wg21.link/P2536R0>
> where I am proposing a way which does not require module name “encoding” in
> the file system and still provides all information needed to rebuild any
> module.
>
>
>
> In short, I propose that we have a .d.json file near each BMI (prebuilt or
> built from a user code) containing all info required to rebuild that
> module. I argue that we don’t really need anything else (besides user build
> info) to be able to rebuild any module.
>
>
>
> I also argue that those .d.json files can and should be automatically
> produced by the build/compilers, thus removing the maintenance burden from
> the users.
>
>
>
> Thanks,
>
> Olga
>
>
>
>
> I will read it, but I'll say to start that the discovery problem still
exists. Nearby the BMI only tells me something if I have already found it.
Finding the information about module xyzzy is part of the challenge, and
the universe of places to look can be very very large.

That it's challenging to produce file names based on changes to in-source
names that could be in any file was why we had P1427R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1427r0.pdf>back
in 2018. We've had deep concerns about tooling for modules forever.