Modules TS Work

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Modules TS Work

Yvan Roux via cfe-dev

Hello,

I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.

-Matt
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):

>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev
Yeah, Richard seems to be working on modules TS features when he has time amongst other priorities.

Any particular areas you've found gaps you've been interested in filling?

On Sat, Sep 29, 2018 at 8:15 AM Matt Asplund (mwasplund) via cfe-dev <[hidden email]> wrote:

Hello,

I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.

-Matt
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on or if I should be sending out my own patches. I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev


On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on

Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 
or if I should be sending out my own patches.

Generally welcome, I should think! :)
 
I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 


Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)
 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
I have not had a chance to pull down and build the branch of gcc that has the modules-ts implementation yet. From reading the spec I did not think that macro definitions within a single translation unit would be affected by it being a module unit at all, much less a previously defined macro in the module interface unit. I was testing some with MSVC (until I hit a not implemented error) and they seem to allow this scenario.

-Matt

On Sun, Oct 7, 2018 at 5:55 PM David Blaikie <[hidden email]> wrote:


On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on

Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 
or if I should be sending out my own patches.

Generally welcome, I should think! :)
 
I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 


Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)
 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
I also feel that the precompiled header file format as it is today is not the best fit for the module-ts interface definition. Would it not be more straightforward to have the compilation of an interface module generate a simplified form of this file that only contains the types and declarations that were exported along with an object file? It feels cumbersome at best to generate this entire file and then turn around and spit out the object file in a second call. 

On a side note, would anyone be opposed to lifting the requirement that a interface module translation unit using the cppm extension? The spec simply says a translation unit will be treated as a module unit if it contains a module declaration and clang seems to already allow this for implementation modules. 

On Sun, Oct 7, 2018 at 6:19 PM Matt Asplund <[hidden email]> wrote:
I have not had a chance to pull down and build the branch of gcc that has the modules-ts implementation yet. From reading the spec I did not think that macro definitions within a single translation unit would be affected by it being a module unit at all, much less a previously defined macro in the module interface unit. I was testing some with MSVC (until I hit a not implemented error) and they seem to allow this scenario.

-Matt

On Sun, Oct 7, 2018 at 5:55 PM David Blaikie <[hidden email]> wrote:


On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on

Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 
or if I should be sending out my own patches.

Generally welcome, I should think! :)
 
I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 


Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)
 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
Sorry to keep responding to myself, FYI the documentation for precompiled header file format is another great example of how it is hard to keep track of when modules refers to clang modules or the modules ts...

-Matt

On Sun, Oct 7, 2018 at 10:23 PM Matt Asplund <[hidden email]> wrote:
I also feel that the precompiled header file format as it is today is not the best fit for the module-ts interface definition. Would it not be more straightforward to have the compilation of an interface module generate a simplified form of this file that only contains the types and declarations that were exported along with an object file? It feels cumbersome at best to generate this entire file and then turn around and spit out the object file in a second call. 

On a side note, would anyone be opposed to lifting the requirement that a interface module translation unit using the cppm extension? The spec simply says a translation unit will be treated as a module unit if it contains a module declaration and clang seems to already allow this for implementation modules. 

On Sun, Oct 7, 2018 at 6:19 PM Matt Asplund <[hidden email]> wrote:
I have not had a chance to pull down and build the branch of gcc that has the modules-ts implementation yet. From reading the spec I did not think that macro definitions within a single translation unit would be affected by it being a module unit at all, much less a previously defined macro in the module interface unit. I was testing some with MSVC (until I hit a not implemented error) and they seem to allow this scenario.

-Matt

On Sun, Oct 7, 2018 at 5:55 PM David Blaikie <[hidden email]> wrote:


On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on

Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 
or if I should be sending out my own patches.

Generally welcome, I should think! :)
 
I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 


Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)
 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev

And the current documentation about „Modules” doesn't say a thing about Modules-TS. Or I'm going blind…

 

My implementation so far is coming along nicely, I believe I’ll have it done in the upcoming week or so. Currently had to travel midway of writing a command which is not fun.

 

; W.

 

From: [hidden email]
Sent: 2018. október 8., hétfő 7:25
To: [hidden email]
Cc: [hidden email]; [hidden email]; [hidden email]
Subject: Re: [cfe-dev] Modules TS Work

 

Sorry to keep responding to myself, FYI the documentation for precompiled header file format is another great example of how it is hard to keep track of when modules refers to clang modules or the modules ts...

 

-Matt

 

On Sun, Oct 7, 2018 at 10:23 PM Matt Asplund <[hidden email]> wrote:

I also feel that the precompiled header file format as it is today is not the best fit for the module-ts interface definition. Would it not be more straightforward to have the compilation of an interface module generate a simplified form of this file that only contains the types and declarations that were exported along with an object file? It feels cumbersome at best to generate this entire file and then turn around and spit out the object file in a second call. 

 

On a side note, would anyone be opposed to lifting the requirement that a interface module translation unit using the cppm extension? The spec simply says a translation unit will be treated as a module unit if it contains a module declaration and clang seems to already allow this for implementation modules. 

 

On Sun, Oct 7, 2018 at 6:19 PM Matt Asplund <[hidden email]> wrote:

I have not had a chance to pull down and build the branch of gcc that has the modules-ts implementation yet. From reading the spec I did not think that macro definitions within a single translation unit would be affected by it being a module unit at all, much less a previously defined macro in the module interface unit. I was testing some with MSVC (until I hit a not implemented error) and they seem to allow this scenario.

 

-Matt

 

On Sun, Oct 7, 2018 at 5:55 PM David Blaikie <[hidden email]> wrote:

 

On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:

I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on


Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 

or if I should be sending out my own patches.


Generally welcome, I should think! :)
 

I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 


Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

 

The issue I am stuck on right now is this:

Bug 39206 - [Modules TS] Macro defined in module interface cannot be set in implementation 

 

 

Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)

 

 

-Matt

 

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:

CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.

 

 

Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:

 

On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:

I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.


I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 


; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):


>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev


On Sun, Oct 7, 2018 at 10:23 PM Matt Asplund <[hidden email]> wrote:
I also feel that the precompiled header file format as it is today is not the best fit for the module-ts interface definition.

What particular problems/mismatches do you see/find in this?
 
Would it not be more straightforward to have the compilation of an interface module generate a simplified form of this file that only contains the types and declarations that were exported

By simplified form you mean a valid C++ file, but stripped of all the non-exported features?

That wouldn't achieve the performance goals/desires of Clang's modules (either Clang Modules, or ModulesTS modules) support - compiler performance. The idea is to avoid having to re-parse the source for every use. The bitcode/pcm/pch format is intended to be efficient to query/lazy load (it contains name lookup tables, structures that can be mapped in from disk and read only when needed, etc).
 
along with an object file? It feels cumbersome at best to generate this entire file and then turn around and spit out the object file in a second call. 

It's possible to support .pcm+.o file generation at the same time - and I imagine Clang will support that eventually depending on what sort of build system preferences evolve, and how things align between Clang and GCC ModulesTS support.

But that said, there's good reason/benefits to doing this as two separate steps - it improves build parallelism, allowing builds that use a module to begin before code generation for that module begins (or in parallel with it). Rather than having to wait until the object file generation is completed before downstream modules or other source files can begin compiling.
 
On a side note, would anyone be opposed to lifting the requirement that a interface module translation unit using the cppm extension? The spec simply says a translation unit will be treated as a module unit if it contains a module declaration and clang seems to already allow this for implementation modules. 

Possible, sure - though personally I sort of hope this is an opportunity to reduce the proliferation of different C++ file extensions & just standardize on one.

- Dave
 

On Sun, Oct 7, 2018 at 6:19 PM Matt Asplund <[hidden email]> wrote:
I have not had a chance to pull down and build the branch of gcc that has the modules-ts implementation yet. From reading the spec I did not think that macro definitions within a single translation unit would be affected by it being a module unit at all, much less a previously defined macro in the module interface unit. I was testing some with MSVC (until I hit a not implemented error) and they seem to allow this scenario.

-Matt

On Sun, Oct 7, 2018 at 5:55 PM David Blaikie <[hidden email]> wrote:


On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on

Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 
or if I should be sending out my own patches.

Generally welcome, I should think! :)
 
I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 


Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)
 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
It isn't so much that the file format has problems or is mismatched, my main concern is that it has too much information to be used as a interface consumption device. The pcm file has all of the required information to compile the original module source, which seems like over kill when being passed in as a definition for the public exported symbols during compilation of the implementation or other module units that import it. I would think a we could use the same file format but allow for the preprocessor, method pool etc to be optional and possibly save a trimmed AST that strips out any implementation details. Has there been a performance comparison for the difference between direct to object compilation and cpp -> pcm -> o?  Would it be worth investigating a second file extension that is a simplified form for a precompiled interface? Possibly (cpp -> pcm + pci) then parallel (pcm -> o) and pci for reference.

Another reason I am hesitant to rely entirely on the pcm file format today is for build tooling in the future. In the past the precompiled header was entirely an implementation detail of the compiler itself, but it is my hope that these module definition files can be directly integrated into build tooling and it would be awesome to work toward a compile agnostic file format here. For example, a symbol servers of the future could support a single file type that all compiles use as a in intermediate collection of symbols for speedy intellisense when referencing modules!

As for the cppm file extension, it sounds like we have the same concerns, but different solutions. It was my hope that I could standardize the file format for all of my source files to a single extension (I prefer *.cpp) and not require that a module translation unit also have an "m" at the end. Either way, this sounds like a problem that a build system should be trying to solve, not the compiler.

-Matt

On Mon, Oct 8, 2018 at 8:55 AM David Blaikie <[hidden email]> wrote:


On Sun, Oct 7, 2018 at 10:23 PM Matt Asplund <[hidden email]> wrote:
I also feel that the precompiled header file format as it is today is not the best fit for the module-ts interface definition.

What particular problems/mismatches do you see/find in this?
 
Would it not be more straightforward to have the compilation of an interface module generate a simplified form of this file that only contains the types and declarations that were exported

By simplified form you mean a valid C++ file, but stripped of all the non-exported features?

That wouldn't achieve the performance goals/desires of Clang's modules (either Clang Modules, or ModulesTS modules) support - compiler performance. The idea is to avoid having to re-parse the source for every use. The bitcode/pcm/pch format is intended to be efficient to query/lazy load (it contains name lookup tables, structures that can be mapped in from disk and read only when needed, etc).
 
along with an object file? It feels cumbersome at best to generate this entire file and then turn around and spit out the object file in a second call. 

It's possible to support .pcm+.o file generation at the same time - and I imagine Clang will support that eventually depending on what sort of build system preferences evolve, and how things align between Clang and GCC ModulesTS support.

But that said, there's good reason/benefits to doing this as two separate steps - it improves build parallelism, allowing builds that use a module to begin before code generation for that module begins (or in parallel with it). Rather than having to wait until the object file generation is completed before downstream modules or other source files can begin compiling.
 
On a side note, would anyone be opposed to lifting the requirement that a interface module translation unit using the cppm extension? The spec simply says a translation unit will be treated as a module unit if it contains a module declaration and clang seems to already allow this for implementation modules. 

Possible, sure - though personally I sort of hope this is an opportunity to reduce the proliferation of different C++ file extensions & just standardize on one.

- Dave
 

On Sun, Oct 7, 2018 at 6:19 PM Matt Asplund <[hidden email]> wrote:
I have not had a chance to pull down and build the branch of gcc that has the modules-ts implementation yet. From reading the spec I did not think that macro definitions within a single translation unit would be affected by it being a module unit at all, much less a previously defined macro in the module interface unit. I was testing some with MSVC (until I hit a not implemented error) and they seem to allow this scenario.

-Matt

On Sun, Oct 7, 2018 at 5:55 PM David Blaikie <[hidden email]> wrote:


On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on

Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 
or if I should be sending out my own patches.

Generally welcome, I should think! :)
 
I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 


Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)
 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev


On Mon, Oct 8, 2018 at 10:03 AM Matt Asplund <[hidden email]> wrote:
It isn't so much that the file format has problems or is mismatched, my main concern is that it has too much information to be used as a interface consumption device. The pcm file has all of the required information to compile the original module source, which seems like over kill when being passed in as a definition for the public exported symbols during compilation of the implementation or other module units that import it.

Yeah, some bits might be removable - but a lot of it you probably still want there (& the things in the pcm are only the bits from the module interface file - developers can still separate the implementation of the module out into separate files so they wouldn't be part of the pcm) - for example non-exported things that are used from exported things. They would still be necessary or at least useful for optimization purposes, etc.
 
I would think a we could use the same file format but allow for the preprocessor, method pool etc to be optional

Not sure the preprocessing information could be optional - macros can be exported from modules (maybe only legacy modules? I forget) and are needed for diagnostic (warnings/errors) accuracy too. (not sure what constitutes the "method pool" - but probably similar issues)
 
and possibly save a trimmed AST that strips out any implementation details. Has there been a performance comparison for the difference between direct to object compilation and cpp -> pcm -> o?

Don't think so.
 
  Would it be worth investigating a second file extension that is a simplified form for a precompiled interface? Possibly (cpp -> pcm + pci) then parallel (pcm -> o) and pci for reference.

Maybe - though probably wouldn't need another file extension I guess (well, in the sense that pch and pcm use the same format but different extensions, I guess this other thing could use another extension but the same format)
 
Another reason I am hesitant to rely entirely on the pcm file format today is for build tooling in the future. In the past the precompiled header was entirely an implementation detail of the compiler itself, but it is my hope that these module definition files can be directly integrated into build tooling and it would be awesome to work toward a compile agnostic file format here.

That's a pretty major non-goal for modules at this point. For efficiency (the memory mapping, etc rather than having to fully parse the file, etc) and extensibility (supporting different vendor extensions, quirks, etc) the format of Clang's binary module representations is tightly version locked - trying to standardize even just on Clang's modules would be a pretty big project & drag on future development (having to define how to serialize and deserialize all AST features in an even more deliberate way than it's done now) and standardizing across compiler vendors would be even more awkward.
 
For example, a symbol servers of the future could support a single file type that all compiles use as a in intermediate collection of symbols for speedy intellisense when referencing modules!

As for the cppm file extension, it sounds like we have the same concerns, but different solutions. It was my hope that I could standardize the file format for all of my source files to a single extension (I prefer *.cpp) and not require that a module translation unit also have an "m" at the end. Either way, this sounds like a problem that a build system should be trying to solve, not the compiler.

Not sure I follow that last bit. (but yeah, perhaps we don't need a separate extension for modules - if that's the case then there's no real opportunity to standardize on one extension - all the existing/old extensions would continue to be as valid in the future as they are now)
 

-Matt

On Mon, Oct 8, 2018 at 8:55 AM David Blaikie <[hidden email]> wrote:


On Sun, Oct 7, 2018 at 10:23 PM Matt Asplund <[hidden email]> wrote:
I also feel that the precompiled header file format as it is today is not the best fit for the module-ts interface definition.

What particular problems/mismatches do you see/find in this?
 
Would it not be more straightforward to have the compilation of an interface module generate a simplified form of this file that only contains the types and declarations that were exported

By simplified form you mean a valid C++ file, but stripped of all the non-exported features?

That wouldn't achieve the performance goals/desires of Clang's modules (either Clang Modules, or ModulesTS modules) support - compiler performance. The idea is to avoid having to re-parse the source for every use. The bitcode/pcm/pch format is intended to be efficient to query/lazy load (it contains name lookup tables, structures that can be mapped in from disk and read only when needed, etc).
 
along with an object file? It feels cumbersome at best to generate this entire file and then turn around and spit out the object file in a second call. 

It's possible to support .pcm+.o file generation at the same time - and I imagine Clang will support that eventually depending on what sort of build system preferences evolve, and how things align between Clang and GCC ModulesTS support.

But that said, there's good reason/benefits to doing this as two separate steps - it improves build parallelism, allowing builds that use a module to begin before code generation for that module begins (or in parallel with it). Rather than having to wait until the object file generation is completed before downstream modules or other source files can begin compiling.
 
On a side note, would anyone be opposed to lifting the requirement that a interface module translation unit using the cppm extension? The spec simply says a translation unit will be treated as a module unit if it contains a module declaration and clang seems to already allow this for implementation modules. 

Possible, sure - though personally I sort of hope this is an opportunity to reduce the proliferation of different C++ file extensions & just standardize on one.

- Dave
 

On Sun, Oct 7, 2018 at 6:19 PM Matt Asplund <[hidden email]> wrote:
I have not had a chance to pull down and build the branch of gcc that has the modules-ts implementation yet. From reading the spec I did not think that macro definitions within a single translation unit would be affected by it being a module unit at all, much less a previously defined macro in the module interface unit. I was testing some with MSVC (until I hit a not implemented error) and they seem to allow this scenario.

-Matt

On Sun, Oct 7, 2018 at 5:55 PM David Blaikie <[hidden email]> wrote:


On Sat, Oct 6, 2018 at 5:46 PM Matt Asplund via cfe-dev <[hidden email]> wrote:
I have been finding a few bugs in the modules-ts implementation and wanted to know if this is still being actively work on

Certainly being actively worked on - mostly/entirely by Richard Smith (cc'd) & I think he's prioritizing some of the nastier edge cases as they come up in the standardization process, so "practical" bugs (once where the desired behavior is clear enough & it isn't likely to significantly impact the design/implementation in a significant way) might be a bit lower priority.
 
or if I should be sending out my own patches.

Generally welcome, I should think! :)
 
I am also finding it hard to track what work is being done with clang modules and what work pertains to ModulesTS (Most notably there is only one bucket for bug reporting under modules). 

Fair - though they're pretty related - not sure it's worth having a separate bucket. But not a big deal either way.
 

The issue I am stuck on right now is this:
Bug 39206 [Modules TS] Macro defined in module interface cannot be set in implementation 


Thanks for filing! :) (what does GCC do, I wonder? Not sure if the support over there is near enough to support things)
 

-Matt

On Fri, Oct 5, 2018 at 4:32 PM André Jansen Medeiros Villar via cfe-dev <[hidden email]> wrote:
CC Boris Kolpackov who has the only implamentation of Modules on a build system that i know of.


Em qui, 4 de out de 2018 às 15:04, David Blaikie via cfe-dev <[hidden email]> escreveu:


On Sun, Sep 30, 2018 at 2:32 AM Whisperity via cfe-dev <[hidden email]> wrote:
I am just trying to improve CMake a bit to better explain directives
for codes that use and depend on modules, instead of using nasty
shadow targets and hacks. We also need to improve CMake so it knows
dependencies: I ran into the issue that once I build the module PCM
there is no check (neither from CMake's, nor Clang's side) whether the
source file for that module was changed. Sometimes it keeps the PCM
implementation ignoring the original one, sometimes just runs Clang
into a nasty stack trace.

I'm super interested in CMake support for modules (both Clang's back-compat modules (with modulemaps) and C++ standard modules) - I'll be talking at the developer meeting about some of the issues around Modules TS build system impact (following on from the talk I gave last year on modular code generation) & honestly would love to have a CMake prototype/demo (for clang back-compat modules and/or modules TS modules), with the intent to get something usable for self-hosting one form of explicit modules or another (modular code generation, etc) with the LLVM build, but not sure I really have the CMake skills to pull that off in time.

- Dave
 

; Whisperity.
Matt Asplund (mwasplund) via cfe-dev <[hidden email]> ezt írta
(időpont: 2018. szept. 29., Szo, 17:15):
>
>
> Hello,
>
> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>
> -Matt
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev
As I have now delved a bit into the Modules TS implementation from a
user standpoint (due to having implemented support for it in CMake,
see the patch here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/2482 )
(Some of these concerns are already voiced by Boris in
https://build2.org/article/cxx-modules-misconceptions.xhtml#build )

 1. The first big issue is that while the "C++98 Modules" is somewhat
well-documented, the "Modules TS" has absolutely no workable
documentation available at all... I had to resort to looking up
Clang's option td files to figure out what this thing is supposed to
do.

 2. Currently, Clang is wonky on how modules can be found. You need to
explicitly specify the modules' location which (the prebuilt, if you
want to allow caching of PCMs and no re-read of CPPM files all the
time...) has to be a single folder. The PCM must be available prior to
compilation so the main file is semantically correct, but *it also has
to be linked* against the resulting binary, otherwise implementations
will provide linker errors. (If I link .o instead of .pcm, it will
still work, and .o files are smaller than PCMs, but compilation will
have to semantically analyse the CPPM file providing no speedup on
module contents.) There is no direct sanity check that I'm linking the
same PCM that I used for compiling, and it looks like the PCM must be
linked *explicitly* (so the '-fprebuilt-modules-path' doesn't work
here.)

 3. This might be very CMake specific or I only found this issue
because working on CMake recently, but it is a real pain the behind to
figure out on which modules a translation unit depends. Unlike '-M'
which nicely spits out imports, the only option I saw so far is to
grep for the import statements and then try to map these to the module
files under the prebuild folder. (This is one of the issues I just
didn't succeed (perhaps yet?) in CMake because CMake is also
*somewhat* wonky, at dependency check time it does not know about
other targets and configuration, so I just can't implictly and
automatically say "Okay now please depend on
./whatever/path/mymodule.pcm or it's corresponding cppm input...)
I think this eventually needs to be considered because -M respects
compiler options when resolving the headers, so I think it's logical
that -M (or "-fmodules-list-dependencies" or whatever...) could also
respect where the prebuild dir is and spit out the PCM paths (or even
better the original CPPMs' -- I think PCM contains a backwards link to
where it was built from?) the TU depends on.

Regards,
Whisperity.
David Blaikie via cfe-dev <[hidden email]> ezt írta (időpont:
2018. okt. 4., Cs, 20:02):

>
> Yeah, Richard seems to be working on modules TS features when he has time amongst other priorities.
>
> Any particular areas you've found gaps you've been interested in filling?
>
> On Sat, Sep 29, 2018 at 8:15 AM Matt Asplund (mwasplund) via cfe-dev <[hidden email]> wrote:
>>
>>
>> Hello,
>>
>> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>>
>> -Matt
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev


On Sat, Oct 13, 2018 at 4:41 AM Whisperity <[hidden email]> wrote:
As I have now delved a bit into the Modules TS implementation from a
user standpoint (due to having implemented support for it in CMake,
see the patch here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/2482 )
(Some of these concerns are already voiced by Boris in
https://build2.org/article/cxx-modules-misconceptions.xhtml#build )

 1. The first big issue is that while the "C++98 Modules" is somewhat
well-documented, the "Modules TS" has absolutely no workable
documentation available at all... I had to resort to looking up
Clang's option td files to figure out what this thing is supposed to
do.

Fair cop - work in progress, etc. Though it's far enough along it could probably use some documentation even if it said clearly "this is in flux, may be out of date, etc".
 
 2. Currently, Clang is wonky on how modules can be found. You need to
explicitly specify the modules' location which (the prebuilt, if you
want to allow caching of PCMs and no re-read of CPPM files all the
time...) has to be a single folder.

What command line are you referring to here? -fmodule-cache-path?

That's more used around the "implicit modules" support, which isn't likely to be supported/useful for ModulesTS style modules (becaues you'll want, maybe need, to build object files from the module files - so your build system would need to be aware of building module files).
 
The PCM must be available prior to
compilation so the main file is semantically correct, but *it also has
to be linked* against the resulting binary, otherwise implementations
will provide linker errors. (If I link .o instead of .pcm, it will
still work, and .o files are smaller than PCMs, but compilation will
have to semantically analyse the CPPM file providing no speedup on
module contents.) There is no direct sanity check that I'm linking the
same PCM that I used for compiling, and it looks like the PCM must be
linked *explicitly* (so the '-fprebuilt-modules-path' doesn't work
here.)

yep, the build model currently is entirely explicit, something like this

COMMON_FLAGS="-cc1 -xc++ -emit-module -fmodules -w"
CLANG=clang
$CLANG $COMMON_FLAGS -fmodule-name=foo foo.cppmap -o foo.pcm -fmodules-codegen
$CLANG $COMMON_FLAGS -fmodule-name=bar bar.cppmap -o bar.pcm -fmodules-codegen -fmodule-file=foo.pcm
$CLANG -c foo.pcm
$CLANG -c bar.pcm
$CLANG -cc1 -emit-obj -fmodules -fmodule-file=foo.pcm -fmodule-file=bar.pcm use.cpp
$CLANG foo.o bar.o use.o

Basically - build the .pcms, use those pcms to build object files for the pcms, and use the pcms to help build the object file for the user, then link all the objects together as usual.

3. This might be very CMake specific or I only found this issue
because working on CMake recently, but it is a real pain the behind to
figure out on which modules a translation unit depends. Unlike '-M'
which nicely spits out imports, the only option I saw so far is to
grep for the import statements and then try to map these to the module
files under the prebuild folder. (This is one of the issues I just
didn't succeed (perhaps yet?) in CMake because CMake is also
*somewhat* wonky, at dependency check time it does not know about
other targets and configuration, so I just can't implictly and
automatically say "Okay now please depend on
./whatever/path/mymodule.pcm or it's corresponding cppm input...)
I think this eventually needs to be considered because -M respects
compiler options when resolving the headers, so I think it's logical
that -M (or "-fmodules-list-dependencies" or whatever...) could also
respect where the prebuild dir is and spit out the PCM paths (or even
better the original CPPMs' -- I think PCM contains a backwards link to
where it was built from?) the TU depends on.

Yep, build integration with modules is still very much uncertain/unknown. Experiments/ideas/prototypes are all being played with - but more experiments/design suggestions are welcome.

GCC is prototyping a "callback" system of sorts - when the compiler needs a BMI (binary module interface - Clang's are the .pcm files) it would callback into the build system to ask for the file path of the BMI (so the build system could go off and build it, then inform the compiler where it is).

Clang requires it all explicit at the moment, as I showed above - the build system could either have its own import/inclusion discovery or maybe -M could be expanded to support imports, etc.

- Dave
 

Regards,
Whisperity.
David Blaikie via cfe-dev <[hidden email]> ezt írta (időpont:
2018. okt. 4., Cs, 20:02):
>
> Yeah, Richard seems to be working on modules TS features when he has time amongst other priorities.
>
> Any particular areas you've found gaps you've been interested in filling?
>
> On Sat, Sep 29, 2018 at 8:15 AM Matt Asplund (mwasplund) via cfe-dev <[hidden email]> wrote:
>>
>>
>> Hello,
>>
>> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>>
>> -Matt
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev
In my previous post I have talked about the Modules >>TS<< system.
I've also mentioned "-fprebuilt-modules-path" and also earlier on I
think I've also mentioned "TS". I think the whole modulemap thing will
always be a legacy or a compiler-specific extension, simply because
every effort towards improving Modules TS and eventually getting it
into the real standard does not consider this whole "module map"
thing.

With this in mind, maybe the best course of action is to improve upon
the "Modules TS"(-ish) implementation and get more results out of it
and hit more roadblock to get data on which the eventual "real deal"
is improved with.

Unfortunately, my CMake patch was rejected (or put on hold?) today
because the whole Modules TS thing still being rather new, never
standardised, compiler developers arguing about the internals (just
see this current thread ;) )

David Blaikie <[hidden email]> ezt írta (időpont: 2018. okt. 15., H, 17:30):

>
>
>
> On Sat, Oct 13, 2018 at 4:41 AM Whisperity <[hidden email]> wrote:
>>
>> As I have now delved a bit into the Modules TS implementation from a
>> user standpoint (due to having implemented support for it in CMake,
>> see the patch here:
>> https://gitlab.kitware.com/cmake/cmake/merge_requests/2482 )
>> (Some of these concerns are already voiced by Boris in
>> https://build2.org/article/cxx-modules-misconceptions.xhtml#build )
>>
>>  1. The first big issue is that while the "C++98 Modules" is somewhat
>> well-documented, the "Modules TS" has absolutely no workable
>> documentation available at all... I had to resort to looking up
>> Clang's option td files to figure out what this thing is supposed to
>> do.
>
>
> Fair cop - work in progress, etc. Though it's far enough along it could probably use some documentation even if it said clearly "this is in flux, may be out of date, etc".
>
>>
>>  2. Currently, Clang is wonky on how modules can be found. You need to
>> explicitly specify the modules' location which (the prebuilt, if you
>> want to allow caching of PCMs and no re-read of CPPM files all the
>> time...) has to be a single folder.
>
>
> What command line are you referring to here? -fmodule-cache-path?
>
> That's more used around the "implicit modules" support, which isn't likely to be supported/useful for ModulesTS style modules (becaues you'll want, maybe need, to build object files from the module files - so your build system would need to be aware of building module files).
>
>>
>> The PCM must be available prior to
>> compilation so the main file is semantically correct, but *it also has
>> to be linked* against the resulting binary, otherwise implementations
>> will provide linker errors. (If I link .o instead of .pcm, it will
>> still work, and .o files are smaller than PCMs, but compilation will
>> have to semantically analyse the CPPM file providing no speedup on
>> module contents.) There is no direct sanity check that I'm linking the
>> same PCM that I used for compiling, and it looks like the PCM must be
>> linked *explicitly* (so the '-fprebuilt-modules-path' doesn't work
>> here.)
>
>
> yep, the build model currently is entirely explicit, something like this
>
> COMMON_FLAGS="-cc1 -xc++ -emit-module -fmodules -w"
> CLANG=clang
> $CLANG $COMMON_FLAGS -fmodule-name=foo foo.cppmap -o foo.pcm -fmodules-codegen
> $CLANG $COMMON_FLAGS -fmodule-name=bar bar.cppmap -o bar.pcm -fmodules-codegen -fmodule-file=foo.pcm
> $CLANG -c foo.pcm
> $CLANG -c bar.pcm
> $CLANG -cc1 -emit-obj -fmodules -fmodule-file=foo.pcm -fmodule-file=bar.pcm use.cpp
> $CLANG foo.o bar.o use.o
>
> Basically - build the .pcms, use those pcms to build object files for the pcms, and use the pcms to help build the object file for the user, then link all the objects together as usual.
>
>> 3. This might be very CMake specific or I only found this issue
>> because working on CMake recently, but it is a real pain the behind to
>> figure out on which modules a translation unit depends. Unlike '-M'
>> which nicely spits out imports, the only option I saw so far is to
>> grep for the import statements and then try to map these to the module
>> files under the prebuild folder. (This is one of the issues I just
>> didn't succeed (perhaps yet?) in CMake because CMake is also
>> *somewhat* wonky, at dependency check time it does not know about
>> other targets and configuration, so I just can't implictly and
>> automatically say "Okay now please depend on
>> ./whatever/path/mymodule.pcm or it's corresponding cppm input...)
>> I think this eventually needs to be considered because -M respects
>> compiler options when resolving the headers, so I think it's logical
>> that -M (or "-fmodules-list-dependencies" or whatever...) could also
>> respect where the prebuild dir is and spit out the PCM paths (or even
>> better the original CPPMs' -- I think PCM contains a backwards link to
>> where it was built from?) the TU depends on.
>
>
> Yep, build integration with modules is still very much uncertain/unknown. Experiments/ideas/prototypes are all being played with - but more experiments/design suggestions are welcome.
>
> GCC is prototyping a "callback" system of sorts - when the compiler needs a BMI (binary module interface - Clang's are the .pcm files) it would callback into the build system to ask for the file path of the BMI (so the build system could go off and build it, then inform the compiler where it is).
>
> Clang requires it all explicit at the moment, as I showed above - the build system could either have its own import/inclusion discovery or maybe -M could be expanded to support imports, etc.
>
> - Dave
>
>>
>>
>> Regards,
>> Whisperity.
>> David Blaikie via cfe-dev <[hidden email]> ezt írta (időpont:
>> 2018. okt. 4., Cs, 20:02):
>> >
>> > Yeah, Richard seems to be working on modules TS features when he has time amongst other priorities.
>> >
>> > Any particular areas you've found gaps you've been interested in filling?
>> >
>> > On Sat, Sep 29, 2018 at 8:15 AM Matt Asplund (mwasplund) via cfe-dev <[hidden email]> wrote:
>> >>
>> >>
>> >> Hello,
>> >>
>> >> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>> >>
>> >> -Matt
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> [hidden email]
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > [hidden email]
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules TS Work

Yvan Roux via cfe-dev


On Mon, Oct 15, 2018 at 10:12 AM Whisperity <[hidden email]> wrote:
In my previous post I have talked about the Modules >>TS<< system.
I've also mentioned "-fprebuilt-modules-path" and also earlier on I
think I've also mentioned "TS". I think the whole modulemap thing will
always be a legacy or a compiler-specific extension, simply because
every effort towards improving Modules TS and eventually getting it
into the real standard does not consider this whole "module map"
thing.

True, though the standard doesn't talk about a lot of things (like header search paths) that implementations take for granted these days.

Specifically I think module maps will be part of things for standard legacy modules. Currently my understanding is that legacy modules would be discoverable only by their use as the target of a legacy import - so in theory a compiler/build system could discover and classify headers as such that way, but it's probably not super practical that way (in part because then there'd be lots of duplication for all the parsing of any header that wasn't a target of a legacy module import - but only used indirectly by legacy modules).

So I think there might still be some room/motivation for modulemap style support.
 
With this in mind, maybe the best course of action is to improve upon
the "Modules TS"(-ish) implementation and get more results out of it
and hit more roadblock to get data on which the eventual "real deal"
is improved with.

Unfortunately, my CMake patch was rejected (or put on hold?) today
because the whole Modules TS thing still being rather new, never
standardised, compiler developers arguing about the internals (just
see this current thread ;) )

Yeah, perhaps the best that can be done is to come up with prototypes to help inform both the standards effort and the cmake direction when it comes to that.

That said, maybe the fact that modulemaps are already a validated implementation in clang might be a gateway for adding cmake support for that, a shipping/in-use feature. Certainly Clang/LLVM could benefit from being built with that sort of mode (& many other C++ code bases could opt into this).

- Dave
 

David Blaikie <[hidden email]> ezt írta (időpont: 2018. okt. 15., H, 17:30):
>
>
>
> On Sat, Oct 13, 2018 at 4:41 AM Whisperity <[hidden email]> wrote:
>>
>> As I have now delved a bit into the Modules TS implementation from a
>> user standpoint (due to having implemented support for it in CMake,
>> see the patch here:
>> https://gitlab.kitware.com/cmake/cmake/merge_requests/2482 )
>> (Some of these concerns are already voiced by Boris in
>> https://build2.org/article/cxx-modules-misconceptions.xhtml#build )
>>
>>  1. The first big issue is that while the "C++98 Modules" is somewhat
>> well-documented, the "Modules TS" has absolutely no workable
>> documentation available at all... I had to resort to looking up
>> Clang's option td files to figure out what this thing is supposed to
>> do.
>
>
> Fair cop - work in progress, etc. Though it's far enough along it could probably use some documentation even if it said clearly "this is in flux, may be out of date, etc".
>
>>
>>  2. Currently, Clang is wonky on how modules can be found. You need to
>> explicitly specify the modules' location which (the prebuilt, if you
>> want to allow caching of PCMs and no re-read of CPPM files all the
>> time...) has to be a single folder.
>
>
> What command line are you referring to here? -fmodule-cache-path?
>
> That's more used around the "implicit modules" support, which isn't likely to be supported/useful for ModulesTS style modules (becaues you'll want, maybe need, to build object files from the module files - so your build system would need to be aware of building module files).
>
>>
>> The PCM must be available prior to
>> compilation so the main file is semantically correct, but *it also has
>> to be linked* against the resulting binary, otherwise implementations
>> will provide linker errors. (If I link .o instead of .pcm, it will
>> still work, and .o files are smaller than PCMs, but compilation will
>> have to semantically analyse the CPPM file providing no speedup on
>> module contents.) There is no direct sanity check that I'm linking the
>> same PCM that I used for compiling, and it looks like the PCM must be
>> linked *explicitly* (so the '-fprebuilt-modules-path' doesn't work
>> here.)
>
>
> yep, the build model currently is entirely explicit, something like this
>
> COMMON_FLAGS="-cc1 -xc++ -emit-module -fmodules -w"
> CLANG=clang
> $CLANG $COMMON_FLAGS -fmodule-name=foo foo.cppmap -o foo.pcm -fmodules-codegen
> $CLANG $COMMON_FLAGS -fmodule-name=bar bar.cppmap -o bar.pcm -fmodules-codegen -fmodule-file=foo.pcm
> $CLANG -c foo.pcm
> $CLANG -c bar.pcm
> $CLANG -cc1 -emit-obj -fmodules -fmodule-file=foo.pcm -fmodule-file=bar.pcm use.cpp
> $CLANG foo.o bar.o use.o
>
> Basically - build the .pcms, use those pcms to build object files for the pcms, and use the pcms to help build the object file for the user, then link all the objects together as usual.
>
>> 3. This might be very CMake specific or I only found this issue
>> because working on CMake recently, but it is a real pain the behind to
>> figure out on which modules a translation unit depends. Unlike '-M'
>> which nicely spits out imports, the only option I saw so far is to
>> grep for the import statements and then try to map these to the module
>> files under the prebuild folder. (This is one of the issues I just
>> didn't succeed (perhaps yet?) in CMake because CMake is also
>> *somewhat* wonky, at dependency check time it does not know about
>> other targets and configuration, so I just can't implictly and
>> automatically say "Okay now please depend on
>> ./whatever/path/mymodule.pcm or it's corresponding cppm input...)
>> I think this eventually needs to be considered because -M respects
>> compiler options when resolving the headers, so I think it's logical
>> that -M (or "-fmodules-list-dependencies" or whatever...) could also
>> respect where the prebuild dir is and spit out the PCM paths (or even
>> better the original CPPMs' -- I think PCM contains a backwards link to
>> where it was built from?) the TU depends on.
>
>
> Yep, build integration with modules is still very much uncertain/unknown. Experiments/ideas/prototypes are all being played with - but more experiments/design suggestions are welcome.
>
> GCC is prototyping a "callback" system of sorts - when the compiler needs a BMI (binary module interface - Clang's are the .pcm files) it would callback into the build system to ask for the file path of the BMI (so the build system could go off and build it, then inform the compiler where it is).
>
> Clang requires it all explicit at the moment, as I showed above - the build system could either have its own import/inclusion discovery or maybe -M could be expanded to support imports, etc.
>
> - Dave
>
>>
>>
>> Regards,
>> Whisperity.
>> David Blaikie via cfe-dev <[hidden email]> ezt írta (időpont:
>> 2018. okt. 4., Cs, 20:02):
>> >
>> > Yeah, Richard seems to be working on modules TS features when he has time amongst other priorities.
>> >
>> > Any particular areas you've found gaps you've been interested in filling?
>> >
>> > On Sat, Sep 29, 2018 at 8:15 AM Matt Asplund (mwasplund) via cfe-dev <[hidden email]> wrote:
>> >>
>> >>
>> >> Hello,
>> >>
>> >> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.
>> >>
>> >> -Matt
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> [hidden email]
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > [hidden email]
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev