[cfe-dev] Will Clang use PCH format to implement C++20 module system?

[David Blaikie via cfe-dev]

On Tue, Jan 7, 2020 at 10:30 PM Yafei Liu <yfliu at mobvoi.com> wrote:

> So what will happen to package management platforms like apt?
>

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)

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)

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).


> For example, I wrote a module and wanna distribute it on apt, I have three
> possible ways of doing this:
> 1. since precompiled modules to be portable between compilers, I have to
> compile my code with different compilers then upload different modules.
> 2. I upload the source and let the user do the compile.
> 3. I don't use module at all, use the "header+library" old way.
>
> which should be the right way?
>
>
> On Wed, Jan 8, 2020 at 2:38 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>> 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)
>>
>> On Tue, Jan 7, 2020 at 4:10 AM Yafei Liu <yfliu at mobvoi.com> wrote:
>>
>>> 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.
>>>
>>> On Tue, Jan 7, 2020 at 2:30 AM David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 6, 2020 at 2:28 AM Yafei Liu via cfe-dev <
>>>> cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>> 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?
>>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>> 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?
>>>>>
>>>>
>>>> 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.
>>>>
>>>> - Dave
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200108/94416db6/attachment.html>