Date: Mon, 18 Apr 2022 05:28:01 +0000
Hi Nico,
As I am responsible for VC project build implementation, I'd like to clarify couple of things there.
VC projects allow any file extension for the module interface files, as well as any other files in general - user controls what happens with a particular file in the build by modifying its options.
The file extension (what you call suffix, I believe) is only used for assigning default options.
Thus, the files with .ixx and .cppm extensions are assumed to be module interfaces so appropriate options are set for them by default. There is no special file extension for internal partition (and thus no default settings for it) - my understanding that its usage is discouraged. It is still supported, but you have to set the C/C++ 'Compile As' option for its file explicitly now.
So if you just create a VC project with your .cppm files for module interfaces and .cpp for implementation, the only property change you'll need to do is for internal partition file - everything else will happen automatically - scanning, proper build order and command line modification for references.
Some time ago I shared a doc about what msbuild is doing for modules build with SG15, attaching it here again.
I guess it is possible to not rely on the file extension at all, but this requires scanning all sources and will have the following drawbacks:
1. Decreased build throughput as scanning all files is required to determine which ones are modules.
Scan is quick in comparison to compilation, but it is not as simple as in your py script, and requires at least half of the "real" preprocessing. And in the cases where module interface files are not a majority, it is quite a waste of the build time.
1. Worse error reporting - you won't get good errors for files which are supposed to be a module interface but was not recognized as such during scanning or vice versa.
2. C++ editor experience in the IDE - it will take much longer to see semantic colorization and have autocompletion and other intellisense features working there. Again, for big codebases it will be very noticeable.
So having special extensions for module interface files is definitely beneficial for tooling.
I also believe it is beneficial for the users as it aids in discoverability and code understanding, quite similarly to .h* and .c* today and we should encourage people using those special extensions instead of just .cpp, just like in your sample.
Thanks,
Olga
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Nicolai Josuttis via SG15
Sent: Sunday, April 17, 2022 04:09
To: WG21 Tooling Study Group SG15 <sg15_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Nicolai Josuttis <nico_at_[hidden]>
Subject: [SG15] clmod.py (the tool to provide easy use of module examples with Visual C++) is published
As promised, I have published a Python script at
https://github.com/josuttis/cppmodules<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjosuttis%2Fcppmodules&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806308752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4cHHdrrRwW31r%2B7CPRzUsMR03K6v6IkJa9H9LgFpxeI%3D&reserved=0>
The script circumvents the current restrictions of Visual C++ for simple C++ example that want to test modules. I hope this contribution will help to bring modules faster to life.
You can find the script with documentation and test code at the web site. However let me mention a few basic aspects here.
Unlike Visual C++, the script
* allows programmers to use arbitrary file suffixes for module units AND
* does not require to specify options such as /internalPartition or /interface AND
* enables programmers to pass ALL units of a C++ program using modules on ONE command line
As an example, assume for a module ModAll, we have:
* modall_if.cppm : The module interface unit
* modall_ifpart.cppm : An interface partition unit
* modall_part.cppm : An internal partition
* modall_impl.cpp : An implementation unit
and to test this we have:
* modall_test.cpp : A traditional translation unit
Calling:
clmod.py /std:c++latest modall_part.cppm modall_ifpart.cppm modall_if.cppm modall_impl.cpp modall_test.cpp /Femodall.exe
will automatically do the right thing:
cl /std:c++latest /Femodall.exe /TP /c /internalPartition modall_part.cppm
cl /std:c++latest /Femodall.exe /TP /c /interface modall_ifpart.cppm
cl /std:c++latest /Femodall.exe /TP /c /interface modall_if.cppm
cl /std:c++latest /Femodall.exe /TP /c modall_impl.cpp
cl /std:c++latest /Femodall.exe /TP /c modall_test.cpp
cl /std:c++latest /Femodall.exe modall_part.obj modall_ifpart.obj modall_if.obj modall_impl.obj modall_test.obj
Note that the order of the files still matters.
This example also works when using the Visual C++ conventions:
* .ixx for interface units (all other with .cpp or so)
* .cpp for all units (all gcc supports)
Thus, this script does not propose any file suffixes as a convention.
Instead, you now can use any convention to be able to have a first portable C++ program using modules just passing all files to the compiler.
The script is not perfect. One drawback is that it requires compilation by command line. The script is still a workaround until Visual C++ provides this support directly (which should be easy to do). But at least you can now make easy experience with portable module examples not using an IDE.
Hope this helps.
Feedback welcome (please cc me directly as I have not subscribed the SG155 reflector).
Nico
As I am responsible for VC project build implementation, I'd like to clarify couple of things there.
VC projects allow any file extension for the module interface files, as well as any other files in general - user controls what happens with a particular file in the build by modifying its options.
The file extension (what you call suffix, I believe) is only used for assigning default options.
Thus, the files with .ixx and .cppm extensions are assumed to be module interfaces so appropriate options are set for them by default. There is no special file extension for internal partition (and thus no default settings for it) - my understanding that its usage is discouraged. It is still supported, but you have to set the C/C++ 'Compile As' option for its file explicitly now.
So if you just create a VC project with your .cppm files for module interfaces and .cpp for implementation, the only property change you'll need to do is for internal partition file - everything else will happen automatically - scanning, proper build order and command line modification for references.
Some time ago I shared a doc about what msbuild is doing for modules build with SG15, attaching it here again.
I guess it is possible to not rely on the file extension at all, but this requires scanning all sources and will have the following drawbacks:
1. Decreased build throughput as scanning all files is required to determine which ones are modules.
Scan is quick in comparison to compilation, but it is not as simple as in your py script, and requires at least half of the "real" preprocessing. And in the cases where module interface files are not a majority, it is quite a waste of the build time.
1. Worse error reporting - you won't get good errors for files which are supposed to be a module interface but was not recognized as such during scanning or vice versa.
2. C++ editor experience in the IDE - it will take much longer to see semantic colorization and have autocompletion and other intellisense features working there. Again, for big codebases it will be very noticeable.
So having special extensions for module interface files is definitely beneficial for tooling.
I also believe it is beneficial for the users as it aids in discoverability and code understanding, quite similarly to .h* and .c* today and we should encourage people using those special extensions instead of just .cpp, just like in your sample.
Thanks,
Olga
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Nicolai Josuttis via SG15
Sent: Sunday, April 17, 2022 04:09
To: WG21 Tooling Study Group SG15 <sg15_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Nicolai Josuttis <nico_at_[hidden]>
Subject: [SG15] clmod.py (the tool to provide easy use of module examples with Visual C++) is published
As promised, I have published a Python script at
https://github.com/josuttis/cppmodules<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjosuttis%2Fcppmodules&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806308752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4cHHdrrRwW31r%2B7CPRzUsMR03K6v6IkJa9H9LgFpxeI%3D&reserved=0>
The script circumvents the current restrictions of Visual C++ for simple C++ example that want to test modules. I hope this contribution will help to bring modules faster to life.
You can find the script with documentation and test code at the web site. However let me mention a few basic aspects here.
Unlike Visual C++, the script
* allows programmers to use arbitrary file suffixes for module units AND
* does not require to specify options such as /internalPartition or /interface AND
* enables programmers to pass ALL units of a C++ program using modules on ONE command line
As an example, assume for a module ModAll, we have:
* modall_if.cppm : The module interface unit
* modall_ifpart.cppm : An interface partition unit
* modall_part.cppm : An internal partition
* modall_impl.cpp : An implementation unit
and to test this we have:
* modall_test.cpp : A traditional translation unit
Calling:
clmod.py /std:c++latest modall_part.cppm modall_ifpart.cppm modall_if.cppm modall_impl.cpp modall_test.cpp /Femodall.exe
will automatically do the right thing:
cl /std:c++latest /Femodall.exe /TP /c /internalPartition modall_part.cppm
cl /std:c++latest /Femodall.exe /TP /c /interface modall_ifpart.cppm
cl /std:c++latest /Femodall.exe /TP /c /interface modall_if.cppm
cl /std:c++latest /Femodall.exe /TP /c modall_impl.cpp
cl /std:c++latest /Femodall.exe /TP /c modall_test.cpp
cl /std:c++latest /Femodall.exe modall_part.obj modall_ifpart.obj modall_if.obj modall_impl.obj modall_test.obj
Note that the order of the files still matters.
This example also works when using the Visual C++ conventions:
* .ixx for interface units (all other with .cpp or so)
* .cpp for all units (all gcc supports)
Thus, this script does not propose any file suffixes as a convention.
Instead, you now can use any convention to be able to have a first portable C++ program using modules just passing all files to the compiler.
The script is not perfect. One drawback is that it requires compilation by command line. The script is still a workaround until Visual C++ provides this support directly (which should be easy to do). But at least you can now make easy experience with portable module examples not using an IDE.
Hope this helps.
Feedback welcome (please cc me directly as I have not subscribed the SG155 reflector).
Nico
-- --- Nicolai M. Josuttis www.josuttis.de<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806358750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4Qky7QUkaIfftYUPL1cB4YFhInfaUlGpL31CNQyaujY%3D&reserved=0> +49 (0)531 / 129 88 86 +49 (0)700 / JOSUTTIS Books: C++: http://cppstd20.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd20.com%2F&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806358750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JcxewxboAKK68UusvQMYJW61EWUFpl%2FcxhmI4HpNxFM%3D&reserved=0>, http://cppstd17.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd17.com%2F&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806358750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2TObP5ChQa9gOrdQdXK%2Bj8pLsH1UkT%2BPTqyLHFaK%2BIA%3D&reserved=0>, http://cppmove.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppmove.com%2F&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806358750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6nd%2F%2F3s7sX%2F8hQg9nz6Xysl0ek5rqGxyO9zFaqfU4hg%3D&reserved=0>, http://cppstdlib.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstdlib.com%2F&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806358750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=etkseqQDDnFRHr9%2FEQfbK9PQF%2Fnq5eFR87VLuWwrrJk%3D&reserved=0>, http://tmplbook.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftmplbook.com%2F&data=05%7C01%7Colgaark%40microsoft.com%7C811a93a4803f4fd0013c08da2062c2e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637857905806358750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TluhxOw4Dbz7O55lPweclqzUR6usDggCm4dJQkKV%2BBI%3D&reserved=0>
Received on 2022-04-18 05:28:06