Date: Wed, 20 Apr 2022 20:10:09 +0200
Thanks Gaby and all others,
I agree that this is formally nothing to discuss within the C++ standard
committee.
We see a bit the consequence of inventing on the fly instead of
standardizing existing practice.
But if we are interested in the success of modules, we should care.
Simplicity is a key for the success of new ideas.
So, while I agree that we need build systems in projects of significant
size, the question is whether we still keep things as simple as
possible. And the question is which burden we put not the build tools.
IMO a compiler should parse a C++ file while a build system should not
have to do that.
I assume we all know what interesting corner cases can occur to find out
the first two tokens of a C++ unit (outside leading (nested) comment).
Do we really want that all tools that call compilers (build systems,
scripts, and yes, even programmers) find out the module type by parsing
code?
And how long do we want to wait until all possible tools have written
the necessary C++ parser?
My workaround, clmod.py at https://github.com/josuttis/cppmodules took
me half a day, but it is not perfect and I already had to react on
requests to fix possible issues (so the time I need for it grows)?
Do we really pass such a buck to all programmers and tool vendors?
I learned yesterday that the/one reason Microsoft has a problem with
supporting no specific extensions and not specific command-line options
is that they have options to inject headers into c++ source files (/FI
and -include) and want to support that still for module units. They have
to know when starting the compilation, whether it is a module to decide
whether to inject the header file at the front or in the global module
fragment.
I don't know whether that approach is valid at all. But it seems to
hinder Microsoft to come up with a simple clean solution for the problem
(yes, Gaby, formally this is */not /*a "problem", you do everything
standard conforming).
This problem can be solved and should be solve by the compiler. So I
strongly recommend to do that.
If we would agree on "compilers parse; built tools call compilers", I
see only the following options:
*a) There is a portable way so signal (different) module files*
Visual C++ has .ixx for that, but unfortunately that is not standardized.
In addition, there is no suffix for internal partitions although VC++
needs a special option for them (and only for them).
>From what I hear, nobody uses internal partitions yet. So OK, we might
come up with a suffix later.
However, I see a problem of agreeing of a standard suffix like .ixx
(after 5 years we were not successful).
*b) Compilers find out themselves which kind of modules unit they get.*
This is an approach gcc/g++ already runs successfully AFAIU.
As I am not aware of any technical reason not to be able to follow option b)
(with minor effort it is even possible to still inject header files) I
trongly recommend that we all agree on option b).
Yes, we all know now that Microsoft does not agree on option b).
As we don't have two new standard suffixes yet (not even one), that has
the following consequences:
To use modules we have to wait for all possible tools we use to
establish non-portable support for module files. That is each and every
tool needs one way or the other to categorize the various C++ source files.
IIUC, for cmake, the consequence is that "in order to specify C++20
modules, one /must/ use |FILE_SETS| to list the sources"
(see
https://discourse.cmake.org/t/api-design-c-modules-source-listings-and-interface-properties/5389?s=09).
I am not aware of what the other tool vendors do (except me; now
implementing a simple build tool for Visual C++);
but please allow me to ask when do you think that all the major tools
are in a state that we can use modules everywhere.
I currently tell that modules are not ready for commercial use yet. This
is not the only problem. But by waiting until all tool vendors have
implemented a way to categorize or parse C++ source files, we give the
success in the hands outside our control.
I suggest we keep control and solve the other issues and let modules
become a success story.
Hope this helps
Nico
Am 20.04.2022 um 18:08 schrieb Gabriel Dos Reis via Ext:
>
>
>
> * Because build systems are not part of the ISO standards from WG21.
>
>
>
> Compilers aren’t part of the ISO standards from WG21, either!
>
>
>
> -- Gaby
>
>
>
> *From:* Ext <ext-bounces_at_[hidden]> *On Behalf Of *René
> Ferdinand Rivera Morell via Ext
> *Sent:* Wednesday, April 20, 2022 6:49 AM
> *To:* ISO C++ Tooling Study Group <sg15_at_[hidden]>
> *Cc:* René Ferdinand Rivera Morell <grafikrobot_at_[hidden]>; Daniel
> Ruoso <daniel_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; Evolution
> Working Group mailing list <ext_at_[hidden]>; Peter Dimov
> <pdimov_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
> *Subject:* Re: [isocpp-ext] [SG15] Can we expect that all C++ source
> files can have the same suffix?
>
>
>
> On Wed, Apr 20, 2022 at 8:22 AM Daniel Ruoso via SG15
> <sg15_at_[hidden]> wrote:
>
>
> Why do we need to coerce compilers into playing this role?
>
>
>
> Because build systems are not part of the ISO standards from WG21.
> While we can't describe a build ecosystem in an ISO standard, C++ will
> need to be usable without the existence of anything except the "compiler".
>
>
>
> --
>
> -- René Ferdinand Rivera Morell
> -- Don't Assume Anything -- No Supone Nada
> -- Robot Dreams - http://robot-dreams.net
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Frobot-dreams.net%2F&data=05%7C01%7Cgdr%40microsoft.com%7Ce16f43f06fb84d0638aa08da22d49b35%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637860593808263261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ppj1ELU3qTezBWtSVwIbgCaDBhN7dajIk5l%2B27pwntM%3D&reserved=0>
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2022/04/19081.php
I agree that this is formally nothing to discuss within the C++ standard
committee.
We see a bit the consequence of inventing on the fly instead of
standardizing existing practice.
But if we are interested in the success of modules, we should care.
Simplicity is a key for the success of new ideas.
So, while I agree that we need build systems in projects of significant
size, the question is whether we still keep things as simple as
possible. And the question is which burden we put not the build tools.
IMO a compiler should parse a C++ file while a build system should not
have to do that.
I assume we all know what interesting corner cases can occur to find out
the first two tokens of a C++ unit (outside leading (nested) comment).
Do we really want that all tools that call compilers (build systems,
scripts, and yes, even programmers) find out the module type by parsing
code?
And how long do we want to wait until all possible tools have written
the necessary C++ parser?
My workaround, clmod.py at https://github.com/josuttis/cppmodules took
me half a day, but it is not perfect and I already had to react on
requests to fix possible issues (so the time I need for it grows)?
Do we really pass such a buck to all programmers and tool vendors?
I learned yesterday that the/one reason Microsoft has a problem with
supporting no specific extensions and not specific command-line options
is that they have options to inject headers into c++ source files (/FI
and -include) and want to support that still for module units. They have
to know when starting the compilation, whether it is a module to decide
whether to inject the header file at the front or in the global module
fragment.
I don't know whether that approach is valid at all. But it seems to
hinder Microsoft to come up with a simple clean solution for the problem
(yes, Gaby, formally this is */not /*a "problem", you do everything
standard conforming).
This problem can be solved and should be solve by the compiler. So I
strongly recommend to do that.
If we would agree on "compilers parse; built tools call compilers", I
see only the following options:
*a) There is a portable way so signal (different) module files*
Visual C++ has .ixx for that, but unfortunately that is not standardized.
In addition, there is no suffix for internal partitions although VC++
needs a special option for them (and only for them).
>From what I hear, nobody uses internal partitions yet. So OK, we might
come up with a suffix later.
However, I see a problem of agreeing of a standard suffix like .ixx
(after 5 years we were not successful).
*b) Compilers find out themselves which kind of modules unit they get.*
This is an approach gcc/g++ already runs successfully AFAIU.
As I am not aware of any technical reason not to be able to follow option b)
(with minor effort it is even possible to still inject header files) I
trongly recommend that we all agree on option b).
Yes, we all know now that Microsoft does not agree on option b).
As we don't have two new standard suffixes yet (not even one), that has
the following consequences:
To use modules we have to wait for all possible tools we use to
establish non-portable support for module files. That is each and every
tool needs one way or the other to categorize the various C++ source files.
IIUC, for cmake, the consequence is that "in order to specify C++20
modules, one /must/ use |FILE_SETS| to list the sources"
(see
https://discourse.cmake.org/t/api-design-c-modules-source-listings-and-interface-properties/5389?s=09).
I am not aware of what the other tool vendors do (except me; now
implementing a simple build tool for Visual C++);
but please allow me to ask when do you think that all the major tools
are in a state that we can use modules everywhere.
I currently tell that modules are not ready for commercial use yet. This
is not the only problem. But by waiting until all tool vendors have
implemented a way to categorize or parse C++ source files, we give the
success in the hands outside our control.
I suggest we keep control and solve the other issues and let modules
become a success story.
Hope this helps
Nico
Am 20.04.2022 um 18:08 schrieb Gabriel Dos Reis via Ext:
>
>
>
> * Because build systems are not part of the ISO standards from WG21.
>
>
>
> Compilers aren’t part of the ISO standards from WG21, either!
>
>
>
> -- Gaby
>
>
>
> *From:* Ext <ext-bounces_at_[hidden]> *On Behalf Of *René
> Ferdinand Rivera Morell via Ext
> *Sent:* Wednesday, April 20, 2022 6:49 AM
> *To:* ISO C++ Tooling Study Group <sg15_at_[hidden]>
> *Cc:* René Ferdinand Rivera Morell <grafikrobot_at_[hidden]>; Daniel
> Ruoso <daniel_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; Evolution
> Working Group mailing list <ext_at_[hidden]>; Peter Dimov
> <pdimov_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
> *Subject:* Re: [isocpp-ext] [SG15] Can we expect that all C++ source
> files can have the same suffix?
>
>
>
> On Wed, Apr 20, 2022 at 8:22 AM Daniel Ruoso via SG15
> <sg15_at_[hidden]> wrote:
>
>
> Why do we need to coerce compilers into playing this role?
>
>
>
> Because build systems are not part of the ISO standards from WG21.
> While we can't describe a build ecosystem in an ISO standard, C++ will
> need to be usable without the existence of anything except the "compiler".
>
>
>
> --
>
> -- René Ferdinand Rivera Morell
> -- Don't Assume Anything -- No Supone Nada
> -- Robot Dreams - http://robot-dreams.net
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Frobot-dreams.net%2F&data=05%7C01%7Cgdr%40microsoft.com%7Ce16f43f06fb84d0638aa08da22d49b35%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637860593808263261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ppj1ELU3qTezBWtSVwIbgCaDBhN7dajIk5l%2B27pwntM%3D&reserved=0>
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2022/04/19081.php
-- --- Nicolai M. Josuttis www.josuttis.de +49 (0)531 / 129 88 86 +49 (0)700 / JOSUTTIS Books: C++: http://cppstd20.com, http://cppstd17.com, http://cppmove.com, http://cppstdlib.com, http://tmplbook.com
Received on 2022-04-20 18:10:17