<div dir="ltr">by mistake removed the list ... <div><br></div><div>don't know if it is interesting for anybody, but fwd. it</div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">mobi phil</b> <span dir="ltr"><<a href="mailto:mobi@mobiphil.com">mobi@mobiphil.com</a>></span><br>Date: Fri, Dec 19, 2014 at 5:16 PM<br>Subject: Re: [cfe-dev] extending ClangTool libASTUnit saving and loading<br>To: Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br><br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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><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"><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 class="gmail_quote"><span><div>C++ modules are still pretty experimental.<br></div></span></div></blockquote></span><div>so.. this sounds that would be almost impossible to build llvm/clang with modules...</div></div></div></div></blockquote><div><br></div></span><div>Clang and LLVM build fine with modules enabled; we have a buildbot that tests this on every commit. You need a suitably-configured system (with module maps for your C and C++ standard libraries), though.</div></div></div></div></blockquote><div><br></div></span><div>sounds great... any hints about how to build those maps without the risk to burn some google servers with search?</div><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"><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 class=""><div><br></div><div><br></div> <br><div><br></div></span></div></div></div>
</div></div>