<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 5, 2014 at 11:19 AM, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Sean Silva wrote:<br>
<br>
> Currently there is no "dotted path" (e.g. import std.algorithm, or<br>
> whatever) import in C++; #include's are translated into it:<br>
<br>
</span>Right, this is what I was missing from the doc page, thanks!<br>
<br>
The starting point you attached allows me to try to make sense of the rest<br>
of the page.</blockquote><div><br></div><div>We say this, but it's buried in a section about Objective-C; perhaps it should be moved somewhere more prominent:</div><div><br></div><div><div>"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."</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> try looking at -E with modules enabled.<br>
<br>
</span>That's interesting. Usually, the output from -E can be saved to a .i file<br>
and can be compiled. With modules enabled though, a file containing<br>
'@import' is generated, which has no further usefulness. Not that using -E<br>
to create output for further usage, but I'm only making a general remark.</blockquote><div><br></div><div>I think we should add a #pragma clang module_import (or similar) to support this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> You currently have to do everything through module maps; listing your<br>
> header in a module map basically tells clang "I promise you this header<br>
> meets certain assumptions of modularity" (which are really fairly<br>
> reasonable assumptions; e.g. you aren't expecting a certain macro to be<br>
> defined somewhere else in the code).<br>
<br>
</span>This is exactly something I want to experiment with, to get a good feeling<br>
for what the limitations are, with examples.<br>
<span class=""><br>
> in your own module maps for<br>
> C++, I recommend focusing on making sure your headers are hygienic.<br>
<br>
</span>My interest/curiosity is whether module maps can be created for<br>
Qt/KDE/Boost. It seems that module maps for dependencies (such as the std<br>
library) are a prerequisite before that kind of playing around anyway. Is<br>
something floating around already for libc++/libstdc++? Even a trivial one,<br>
not providing separate <a href="http://std.io" target="_blank">std.io</a> etc, but just std?<br></blockquote><div><br></div><div>libc++ already ships with a module map.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
With my 'buildsystem guy/CMake' hat on, I'm also curious how this modules<br>
stuff affects the buildsystems out there. Possibly not very much, because<br>
clang (and hopefully all drivers) will manage the dependency tracking etc.<br>
I'm interested in user frustration and porting pain.<br>
<br>
1) The link directive could be problematic because it seems to assume<br>
library names only, and that paths are specified with -L as needed by the<br>
buildsystem. That's the opposite of CMake philosophy which uses full paths<br>
instead. Some background information here:<br>
<br>
 <a href="http://www.cmake.org/cmake/help/v3.0/policy/CMP0003.html" target="_blank">http://www.cmake.org/cmake/help/v3.0/policy/CMP0003.html</a><br>
<br>
I guess that's not something for clang to worry about, but possibly<br>
something for a 'how to use modules with cmake' document instructing users<br>
to use -fno-autolink.<br>
<br>
2) All module.modulemap files have the same name.<br>
<br>
[Aside: in the doc, the sentence "Module map files are typically named<br>
module.modulemap", but elsewhere on the page it is specified to be a naming<br>
requirement - 'typically' is wrong here]<br></blockquote><div><br></div><div>'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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The 'compiled' module.modulemap is not a distributable. The module.modulemap<br>
file is a distributable. It should be installed with the headers.<br>
<br>
That is, if I build/install the foo package to the /usr/local prefix, I will<br>
get files like:<br>
<br>
 /usr/local/include/foo.h<br>
 /usr/local/include/module.modulemap<br>
<br>
If I build and install bar, then I will get:<br>
<br>
 /usr/local/include/bar.h<br>
 /usr/local/include/module.modulemap<br>
<br>
How do I install foo and bar at the same time to the same prefix? Each<br>
provides files in the same location which are required to be called<br>
"module.modulemap".<br>
<br>
This potentially affects the installation rules written in buildsystems for<br>
foo and bar.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3) cplusplus11 as a 'requires declaration' use is unclear.<br>
<br>
If a user uses static_assert in their header, then they say they require<br>
cplusplus11. MSVC 2010 supports static_assert.<br>
<br>
Similarly, if a user uses constexpr in their header, then they say they<br>
require cplusplus11. MSVC does not support that at all. I can also point to<br>
other 'c++11' features that even the next MSVC release will not support.<br>
<br>
So, is this something that is proposed for standardization?</blockquote><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">How is MSVC<br>
expected to handle such a 'requires declaration'? Will there be a<br>
cplusplus17 requires declaration? When clang implements c++17 partially,<br>
what behavior will be used for the cplusplus17 requires declaration?<br>
<br>
Or do I misunderstand? Is cplusplus11 or similar only suitable for binary<br>
header is available/not available such as the type_traits example, and it<br>
doesn't relate to features required by the header? Does cplusplus11 exist<br>
only for the benefit of std library implementations?</blockquote><div><br></div><div>"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.</div></div></div></div>