Date: Fri, 4 Feb 2022 00:22:57 +0000
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
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Michael Spencer via SG15
Sent: Tuesday, February 1, 2022 15:48
To: Tooling Study Group (SG15) <sg15_at_[hidden]>
Cc: Michael Spencer <bigcheesegs_at_[hidden]>
Subject: [SG15] Meeting on February 4th at 9AM Pacific
Our next meeting is scheduled for Friday February 4th at 9AM-10:30AM Pacific.
Our topics for this meeting will be:
* 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
Meeting Link: https://iso.zoom.us/j/97089073839?pwd=WHdxbzE0cTFkOU1aVWZocjhkSnp2dz09<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiso.zoom.us%2Fj%2F97089073839%3Fpwd%3DWHdxbzE0cTFkOU1aVWZocjhkSnp2dz09&data=04%7C01%7Colgaark%40microsoft.com%7C3841d36abfe94a46dd0208d9e5dd4e6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637793560958196832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bkMrtLreAZKsEZvLMZhP8IBFTVhS4dtp9obDTs6OD%2Bk%3D&reserved=0>
- Michael Spencer
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
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Michael Spencer via SG15
Sent: Tuesday, February 1, 2022 15:48
To: Tooling Study Group (SG15) <sg15_at_[hidden]>
Cc: Michael Spencer <bigcheesegs_at_[hidden]>
Subject: [SG15] Meeting on February 4th at 9AM Pacific
Our next meeting is scheduled for Friday February 4th at 9AM-10:30AM Pacific.
Our topics for this meeting will be:
* 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
Meeting Link: https://iso.zoom.us/j/97089073839?pwd=WHdxbzE0cTFkOU1aVWZocjhkSnp2dz09<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiso.zoom.us%2Fj%2F97089073839%3Fpwd%3DWHdxbzE0cTFkOU1aVWZocjhkSnp2dz09&data=04%7C01%7Colgaark%40microsoft.com%7C3841d36abfe94a46dd0208d9e5dd4e6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637793560958196832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bkMrtLreAZKsEZvLMZhP8IBFTVhS4dtp9obDTs6OD%2Bk%3D&reserved=0>
- Michael Spencer
Received on 2022-02-04 00:23:01