<div dir="ltr"><br><div class="gmail_extra"><br><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:0 0 0 .8ex;border-left:1px #ccc 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.<br>
<span class=""><br>
> 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.<br></blockquote><div><br></div><div>Yeah, it's not clear if this is actually a "bug" since this is what clang is actually doing, but it's still weird to end up with objective C inside your preprocessed C++ file.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 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>My experience has been that the easiest thing is to start out by just doing a "unity module" like</div><div><br></div><div>module foo {</div><div>  header "bar"</div><div>  header "baz"</div><div>  ...</div><div>}</div><div><br></div><div>Just list every file in the directory (possibly recursively). Then just exclude any headers that are causing problems. That should get you up and running pretty fast.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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>
<br>
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>
<br>
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? 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?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
Thanks,<br>
<br>
Steve.<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>