<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 17, 2014 at 1:51 PM, mobi phil <span dir="ltr"><<a href="mailto:mobi@mobiphil.com" target="_blank">mobi@mobiphil.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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><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><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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><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>