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

[Richard Smith]

On Sun, Oct 5, 2014 at 11:19 AM, Stephen Kelly <steveire at gmail.com> wrote:

> 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.


We say this, but it's buried in a section about Objective-C; perhaps it
should be moved somewhere more prominent:

"At present, there is no C or C++ syntax for import declarations. Clang
will track the modules proposal in the C++ committee. See the section
Includes as imports to see how modules get imported today."

> 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.


I think we should add a #pragma clang module_import (or similar) to support
this.

> 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?
>

libc++ already ships with a module map.

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]
>

'typically' is correct; while only 'module.modulemap' is searched for in -I
paths, additional module map files can be specified via -fmodule-map-file=
and 'extern module' declarations, and these files do not need to be named
module.modulemap.

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.
>

One option would be for each library to provide its own module map file,
which you specify on the clang command line with -fmodule-map-file=. I
don't think we necessarily have the right answer for this case yet.

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?


No. Nothing about module maps is proposed for standardization, nor even
guaranteed to be compatible across Clang revisions (yet). So be aware that
if you go and write a bunch of module maps now, you may need to change them
all to keep them working with future versions of Clang (or you may not; we
don't know).

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?


"requires" flags in general only indicate whether a module is available in
a particular build configuration. The header still needs to do whatever
feature checking it would normally do, to avoid using features the compiler
doesn't support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141005/fde252c2/attachment.html>