[Steve]

  * We've had deep concerns about tooling for modules forever.


Correct. But the suggestion of encoding into the filesystem is more of productivity opportunity inhibitor than a solution, which is why it was rejected back then. It is a huge step back.

-- Gaby

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Steve Downey via SG15
Sent: Thursday, February 3, 2022 5:02 PM
To: ISO C++ Tooling Study Group <sg15_at_[hidden]>
Cc: Steve Downey <sdowney_at_[hidden]>
Subject: Re: [SG15] Meeting on February 4th at 9AM Pacific



On Thu, Feb 3, 2022 at 7:23 PM Olga Arkhipova via SG15 <sg15_at_[hidden]<mailto: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%7Cgdr%40microsoft.com%7C7c0514bf02bc4b0aef1008d9e779f939%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637795333930050662%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Jb39qC2cXdQ%2FVqEeVL9cV0Gxkno0suaDb5LsJRcJYMs%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2FP2536R0&data=04%7C01%7Cgdr%40microsoft.com%7C7c0514bf02bc4b0aef1008d9e779f939%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637795333930050662%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LD8EH3%2Fi56JvmRxqPRZfSPmgcyP%2FoathiGQCYYiKwYQ%3D&reserved=0> 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2019%2Fp1427r0.pdf&data=04%7C01%7Cgdr%40microsoft.com%7C7c0514bf02bc4b0aef1008d9e779f939%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637795333930050662%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fiIy4Xh5QXK%2F0SdDNe5Lu36L8%2F8GzDoNnkwKQt2C5NU%3D&reserved=0> back in 2018. We've had deep concerns about tooling for modules forever.