Date: Mon, 26 Aug 2019 11:53:19 -0400
On Mon, Aug 26, 2019 at 10:18:57 -0400, Nathan Sidwell via SG15 wrote:
> The proposals I've seen for a suffix to denote modular interface files
> take the form of changing the traditional c++ suffixes to something else.
>
> 1) There's the discussion of whether the 'c' is replaced by an 'm', but
> that leads to confusion if your suffix is '.cc' (hence the clang
> approach of appending an 'm'.
Agreed. mpp, cppm, mxx, cxxm, etc are all possibilities.
> 2) It requires teaching all your tools (and users) that the new suffix
> means C++.
FWIW, I don't think CMake is going to care much. A target using C++20
(or later) will be treated as if all source files part of that target
and detected as C++ may use modules. If CMake recognizes the extensions
in use and the compiler does as well (I don't think CMake uses `-x`
flags as much as it should), I don't have any real personal preference
here; I wouldn't be surprised if I just keep using cxx as the extension
even in a modules world (it is, after all, still just C++ code).
There *might* be a way to tell CMake "this wants C++20, but doesn't use
modules, so skip the extra stuff for modules", but that would be an
explicit decision.
> 3) With a paired header file/source file source base of the form
> foo/foo.cc or foo.h/foo.cc, converting the header to an interface will
> require either renaming the stem of one of them, or teaching the build
> system that naming the object file from the stem is not right.
CMake already doesn't do this (you get foo.cc.o there, so a shared
extension is no issue). I think this is probably because there are
projects which have done foo.f90 (for the implementation) and foo.c (for
the ABI) side-by-side before.
> These all seem somewhat awkward.
Agreed.
> There's also the issue of module partitions. IIUC the new suffix is to
> denote interfaceness. But module partitions also fall into the same
> boat as primary module interfaces in that regard -- they generate CMIs.
> Naming module partitions with the same suffix as primary interfaces
> seems confusing. What's been discussed about that?
>
> Has there been discussion of naming the module interface by prepending a
> new suffix: foo.m.cc (or foo-m.cc) This avoids the above 3 issues.
> multisuffix files do exist (foo.tar.gz), but perhaps the '-m' form may
> be more palatable?
>
> Further, one could use 'mp' to denote a module partition:
> foo-m.cc -- primary interface
> foo-mp.cc -- partition
> foo.cc -- implementation
I think that introducing `-m` as an additional "pseudo-extension" is
going to be even more awkward. People are going to want to strip that
off for a variety of reasons. Or use `_` instead which is just another
point on that axis.
--Ben
> The proposals I've seen for a suffix to denote modular interface files
> take the form of changing the traditional c++ suffixes to something else.
>
> 1) There's the discussion of whether the 'c' is replaced by an 'm', but
> that leads to confusion if your suffix is '.cc' (hence the clang
> approach of appending an 'm'.
Agreed. mpp, cppm, mxx, cxxm, etc are all possibilities.
> 2) It requires teaching all your tools (and users) that the new suffix
> means C++.
FWIW, I don't think CMake is going to care much. A target using C++20
(or later) will be treated as if all source files part of that target
and detected as C++ may use modules. If CMake recognizes the extensions
in use and the compiler does as well (I don't think CMake uses `-x`
flags as much as it should), I don't have any real personal preference
here; I wouldn't be surprised if I just keep using cxx as the extension
even in a modules world (it is, after all, still just C++ code).
There *might* be a way to tell CMake "this wants C++20, but doesn't use
modules, so skip the extra stuff for modules", but that would be an
explicit decision.
> 3) With a paired header file/source file source base of the form
> foo/foo.cc or foo.h/foo.cc, converting the header to an interface will
> require either renaming the stem of one of them, or teaching the build
> system that naming the object file from the stem is not right.
CMake already doesn't do this (you get foo.cc.o there, so a shared
extension is no issue). I think this is probably because there are
projects which have done foo.f90 (for the implementation) and foo.c (for
the ABI) side-by-side before.
> These all seem somewhat awkward.
Agreed.
> There's also the issue of module partitions. IIUC the new suffix is to
> denote interfaceness. But module partitions also fall into the same
> boat as primary module interfaces in that regard -- they generate CMIs.
> Naming module partitions with the same suffix as primary interfaces
> seems confusing. What's been discussed about that?
>
> Has there been discussion of naming the module interface by prepending a
> new suffix: foo.m.cc (or foo-m.cc) This avoids the above 3 issues.
> multisuffix files do exist (foo.tar.gz), but perhaps the '-m' form may
> be more palatable?
>
> Further, one could use 'mp' to denote a module partition:
> foo-m.cc -- primary interface
> foo-mp.cc -- partition
> foo.cc -- implementation
I think that introducing `-m` as an additional "pseudo-extension" is
going to be even more awkward. People are going to want to strip that
off for a variety of reasons. Or use `_` instead which is just another
point on that axis.
--Ben
Received on 2019-08-26 10:55:34