<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>put back CC the list, maybe Richard's answer is interesting for somebody else...  </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>First, the C++ standard library: If you're using recent libc++, you already have module maps for it. If you're using libstdc++, I can't help -- I don't have such a module map.<br></div><div><br></div><div>Then the C standard library: I have a module map for glibc that I've been using for a year or so, and it's needed very little maintenance. One additional tweak needed is to move around some of the contents of <assert.h>, because it does things which are hostile to modules. I can provide you with a patch if you like.</div></div></div></div></blockquote><div><br></div><div>hm.. it seems that the threshold is a bit high. I thought producing modules would work straightforward with any library or library headers. So I need to patch the full glibc source or just the headers? Well I did read the article on "<a href="http://clang.llvm.org/docs/Modules.html">http://clang.llvm.org/docs/Modules.html</a>" but my understanding of modules is still poor, so will need some time to catch-up, but the patch may be useful at a certain moment, thanks.</div><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>If you're using a recent Mac OS system, you already have module maps for your C standard library, but ... they're not compatible with C++. With a little manual effort, you could probably get them working.</div><span class=""><div></div></span></div></div></div></blockquote><div><br></div><div>I develop on a ubuntu </div><div><br></div><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>now back to "clang -c Sema.ast" ... isn't it fair to intuitively assume that it would treat the ast as a precompiled unit with all the ingredients (headers) instead of PCH? In best case clang should recognize what kind of ast is behind and behave accordingly?</div></div></div></div></blockquote><div><br></div></span><div>That's a reasonable assumption, but the question is, what code should we generate when you compile from an AST file like this? Right now, we generate code for all the externally-visible definitions in the AST file (and we do the same thing whether the AST file is a preamble, a PCH, or a module). That's liable to change in the future (in particular, we may introduce a mechanism to say "do not generate definitions for an inline function in a module in every user of the module; instead, generate the code once from the module itself").</div></div></div></div>
</blockquote></span></div><div class="gmail_extra"><br></div>well, for me the answer is simple and my reasoning is based on a probably over-simplified assumption and that is maybe I am intrigued. (Do I miss sthg?) So for me for instance</div><div class="gmail_extra"><br>clang -c $SEMA_DIR/Sema.cpp -o Sema.o $BUNCH_OF_COMPILER_FLAGS</div><div class="gmail_extra">#should be equivalent with the pair of commands</div><div class="gmail_extra"><div>clang -emit-ast $SEMA_DIR/Sema.cpp -o Sema.ast $BUNCH_OF_COMPILER_FLAGS<br></div><div>#and</div><div>clang -c Sema.ast -o Sema.o $MAYBE_SOME_EXTRA_FLAGS<br></div><span><div><br></div><div><br></div> <br><div>rgrds,<br>mobi phil<br><br>being mobile, but including technology<br><a href="http://mobiphil.com" target="_blank">http://mobiphil.com</a></div>
</span></div></div>
</blockquote></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">rgrds,<br>mobi phil<br><br>being mobile, but including technology<br><a href="http://mobiphil.com">http://mobiphil.com</a></div>
</div></div>