<div dir="ltr"><div dir="ltr">On Tue, Jan 7, 2020 at 10:30 PM Yafei Liu <<a href="mailto:yfliu@mobvoi.com">yfliu@mobvoi.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">So what will happen to package management platforms like apt?</div></blockquote><div><br></div><div>To my knowledge, that's still somewhat unknown. But it'll necessarily be some form of (2) for the code that's in module interface units. The module implementations can be precompiled, as library implementations are today. (I think I have the terminology right there, hopefully)<br><br>Note that even if precompiled modules could be used between implementations, different flags would generally make them unusable anyway (eg: when you ship your library you can't know ahead of time all the platforms the user might want to compile your code for - maybe they want to compile it on a system with a 32 bit pointer, and another with a 64 bit pointer, etc - and if you make a module fully independent of all of that, it's not much better than source code - so modules necessarily encode some target-specific knowledge (let alone when you start dealing with macros like NDEBUG, etc - which produce completely different code) & aren't portable between compilations with certain differences - so users will always need the module interface source code to be able to build them for their specific circumstances)<br><br>But header+library's not being removed either, so that's an option too. I hope that a fairly portable distribution model for module interface sources does manifest & probably work somewhat similarly to header search paths (& maybe with automatic library linking discovery, etc - people are talking about how to solve that sort of problem since modules requires revisiting some parts of the build system anyway).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>For example, I wrote a module and wanna distribute it on apt, I have three possible ways of doing this:</div><div>1. since precompiled modules to be portable between compilers, I have to compile my code with different compilers then upload different modules.</div><div>2. I upload the source and let the user do the compile.</div><div>3. I don't use module at all, use the "header+library" old way.</div><div><br></div><div>which should be the right way?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2020 at 2:38 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">It won't - there are no plans for precompiled modules to be portable between compilers. (someone at Microsoft has been having some discussions about maybe making some of that possible - but there's a fair bit of resistance, and so far as I know from Clang and GCC there's no work in that direction)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 7, 2020 at 4:10 AM Yafei Liu <<a href="mailto:yfliu@mobvoi.com" target="_blank">yfliu@mobvoi.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey David, I got another question, do you know how will Clang handle modules which is compiled by other compiler? For example GCC? The AST serialization is not the same.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 7, 2020 at 2:30 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 6, 2020 at 2:28 AM Yafei Liu via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all, I'm curious if the PCH format will be used to implement C++20 module system? Any Clang community discussions or documents on this?</div></blockquote><div><br></div><div>More or less. The basic AST serialization system is already shared between PCH, Clang Header Modules, and preliminary support for C++20 Modules. Not exactly the same, because the semantics of each are slightly different - but the core AST serialization is common across all 3.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>What's more, I'm inventing a language using LLVM, and I want to generate some middle layer to communicate with c++ module, so is there any tools or apis to generate a PCH?<br></div></div></blockquote><div><br>None that I know of. The only cross-language binding like that that I know of is Swift, which is one-way to the best of my knowledge (so Swift doesn't have to generate Clang-compatible AST files (PCH/PCM/whatever) - it only has to be able to read them). I imagine Swift's binary module representation might be similar for ease of interoperability, but I don't actually know.<br><br>- Dave</div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>