[cfe-dev] How do I try out C++ modules with clang?

[Stephen Kelly]

Sean Silva wrote:

> Currently there is no "dotted path" (e.g. import std.algorithm, or
> whatever) import in C++; #include's are translated into it:

Right, this is what I was missing from the doc page, thanks!

The starting point you attached allows me to try to make sense of the rest 
of the page.

> try looking at -E with modules enabled.

That's interesting. Usually, the output from -E can be saved to a .i file 
and can be compiled. With modules enabled though, a file containing 
'@import' is generated, which has no further usefulness. Not that using -E 
to create output for further usage, but I'm only making a general remark.

> You currently have to do everything through module maps; listing your
> header in a module map basically tells clang "I promise you this header
> meets certain assumptions of modularity" (which are really fairly
> reasonable assumptions; e.g. you aren't expecting a certain macro to be
> defined somewhere else in the code).

This is exactly something I want to experiment with, to get a good feeling 
for what the limitations are, with examples.

> in your own module maps for
> C++, I recommend focusing on making sure your headers are hygienic.

My interest/curiosity is whether module maps can be created for 
Qt/KDE/Boost. It seems that module maps for dependencies (such as the std 
library) are a prerequisite before that kind of playing around anyway. Is 
something floating around already for libc++/libstdc++? Even a trivial one, 
not providing separate std.io etc, but just std?

With my 'buildsystem guy/CMake' hat on, I'm also curious how this modules 
stuff affects the buildsystems out there. Possibly not very much, because 
clang (and hopefully all drivers) will manage the dependency tracking etc. 
I'm interested in user frustration and porting pain.

1) The link directive could be problematic because it seems to assume 
library names only, and that paths are specified with -L as needed by the 
buildsystem. That's the opposite of CMake philosophy which uses full paths 
instead. Some background information here:

 http://www.cmake.org/cmake/help/v3.0/policy/CMP0003.html

I guess that's not something for clang to worry about, but possibly 
something for a 'how to use modules with cmake' document instructing users 
to use -fno-autolink.

2) All module.modulemap files have the same name.

[Aside: in the doc, the sentence "Module map files are typically named 
module.modulemap", but elsewhere on the page it is specified to be a naming 
requirement - 'typically' is wrong here]

The 'compiled' module.modulemap is not a distributable. The module.modulemap 
file is a distributable. It should be installed with the headers.

That is, if I build/install the foo package to the /usr/local prefix, I will 
get files like:

 /usr/local/include/foo.h
 /usr/local/include/module.modulemap

If I build and install bar, then I will get:

 /usr/local/include/bar.h
 /usr/local/include/module.modulemap

How do I install foo and bar at the same time to the same prefix? Each 
provides files in the same location which are required to be called 
"module.modulemap".

This potentially affects the installation rules written in buildsystems for 
foo and bar.

3) cplusplus11 as a 'requires declaration' use is unclear.

If a user uses static_assert in their header, then they say they require 
cplusplus11. MSVC 2010 supports static_assert. 

Similarly, if a user uses constexpr in their header, then they say they 
require cplusplus11. MSVC does not support that at all. I can also point to 
other 'c++11' features that even the next MSVC release will not support. 

So, is this something that is proposed for standardization? How is MSVC 
expected to handle such a 'requires declaration'? Will there be a 
cplusplus17 requires declaration? When clang implements c++17 partially, 
what behavior will be used for the cplusplus17 requires declaration?

Or do I misunderstand? Is cplusplus11 or similar only suitable for binary 
header is available/not available such as the type_traits example, and it 
doesn't relate to features required by the header? Does cplusplus11 exist 
only for the benefit of std library implementations?



Thanks,

Steve.