<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 22, 2014 at 3:22 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 <chisophugis@...> writes:<br>
<br>
> Stephen, thanks for being a brave guinea pig here :)<br>
<br>
</span>No problem!<br>
<br>
With the define I get more errors of the form:<br>
<br>
$ clang++ -E -fmodules -fmodules-cache-path=cache -D_USE_EXTENDED_LOCALES_<br>
<span class="">test.cpp<br>
# 1 "test.cpp"<br>
# 1 "<built-in>" 1<br>
# 1 "<built-in>" 3<br>
# 325 "<built-in>" 3<br>
# 1 "<command line>" 1<br>
# 1 "<built-in>" 2<br>
# 1 "test.cpp" 2<br>
While building module 'std' imported from test.cpp:6:<br>
</span>While building module 'Darwin' imported from<br>
/Users/ske/dev/prefix/bin/../include/c++/v1/__config:23:<br>
In file included from <module-includes>:3:<br>
In file included from /usr/include/ctype.h:384:<br>
/usr/include/xlocale/_ctype.h:35:50: error: unknown type name 'locale_t'<br>
unsigned long           ___runetype_l(__darwin_ct_rune_t, locale_t);<br>
                                                          ^<br>
/usr/include/xlocale/_ctype.h:36:53: error: unknown type name 'locale_t'<br>
__darwin_ct_rune_t      ___tolower_l(__darwin_ct_rune_t, locale_t);<br>
                                                         ^<br>
<br>
<br>
Actually I think I hit similar errors from files in /usr/include when I<br>
tried this a few weeks ago on linux, and I think my solution was to add a<br>
modulemap in /usr/include for a few things.</blockquote><div><br></div><div>If you don't modularize bottom-up, the problems you're most likely to run into are submodule visibility problems. Essentially, when a top-level module has multiple submodules which try to textually include the same file (and that file has include guards), only the first submodule to include that file actually includes its contents (for the rest of them, the include guards prevent repeated inclusion), so only that first submodule ends up owning the header's contents. The result is that you can no longer rely on indirect textual #includes to bring in file contents.</div><div><br></div><div>One way to avoid the problem is to avoid using submodules (Sean did this in some of his experiments, and got some good results). Another way is to properly modularize bottom-up (which means starting by fixing the module maps and modularization of your system headers). We've also been discussing ways that Clang could make this transparent by changing its submodules model (so that multiple submodules of the same module *could*, in effect, textually include the same source file).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll check that in a few days.<br>
<br>
This patch allows me to build the libcxx module:<br>
<br>
diff --git a/include/ios b/include/ios<br>
index ff79998..e5dc654 100644<br>
--- a/include/ios<br>
+++ b/include/ios<br>
@@ -213,6 +213,7 @@ storage-class-specifier const error_category&<br>
iostream_category() noexcept;<br>
<br>
 #include <__config><br>
 #include <iosfwd><br>
+#include <cstdlib><br>
 #include <__locale><br>
 #include <system_error><br>
<br>
<br>
Though this stuff is very fiddly, and I have not yet grokked the whole<br>
connection/problem between modules and defines (I haven't passed the 'it<br>
basically works' barrier yet in order to grok that :) ), so I don't know if<br>
the above patch is the right approach.<br>
<br>
I am surprised that this problem has survived as I thought it would be an<br>
obvious "step 1" for anyone trying modules on mac. I guess either it's been<br>
tested so far on a different kind of system, or whoever added the modulemap<br>
for libcxx only tested it on linux. A unit test could be added in libcxx<br>
which attempts to build a module for it, right?</blockquote><div><br></div><div>As far as I know, the libc++ (and LLVM and Clang) module maps have only been successfully used on Linux.  I don't know whether the problems on Mac are from a combination of subtly-incorrect module maps and non-modular system headers, or are caused by Clang bugs (or both).</div></div></div></div>