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:

 

 

Compilers aren’t part of the ISO standards from WG21, either!

 

-- Gaby

 

From: Ext <ext-bounces@lists.isocpp.org> On Behalf Of René Ferdinand Rivera Morell via Ext
Sent: Wednesday, April 20, 2022 6:49 AM
To: ISO C++ Tooling Study Group <sg15@lists.isocpp.org>
Cc: René Ferdinand Rivera Morell <grafikrobot@gmail.com>; Daniel Ruoso <daniel@ruoso.com>; Tom Honermann <tom@honermann.net>; Evolution Working Group mailing list <ext@lists.isocpp.org>; Peter Dimov <pdimov@gmail.com>; Nathan Sidwell <nathan@acm.org>
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@lists.isocpp.org> 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


_______________________________________________
Ext mailing list
Ext@lists.isocpp.org
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