C++ Logo

sg15

Advanced search

Re: [Tooling] [Ext] Modules and tooling: Resolving module import declarations

From: Tom Honermann <tom_at_[hidden]>
Date: Fri, 31 Aug 2018 14:44:22 -0400
On 08/31/2018 01:25 PM, Nathan Sidwell wrote:
> On 08/31/2018 12:05 PM, Tom Honermann wrote:
>
>> Are you referring to the module mapper approach documented at
>> https://gcc.gnu.org/wiki/cxx-modules?
>
> That documentation is pretty opaque. I can only blame myself.

The fact that documentation for an experimental feature exists at all
raises you well above the level at which criticism is justified ;)

>
>> If so, my concern with that approach is that it effectively requires
>> a build system. Perhaps the default module mapper does not (I'm not
>> sure exactly what it does at present. My brief tests indicate it
>> requires a
>
> The defaults it has right now may not be the best defaults. (Hey, you
> can go experiment with better defaults!)

Indeed, I can - and would like to if this discussion reveals an approach
that might have broad agreement.

I'm lobbying for a position in which the default behavior is, if no
suitable module artifact is identified, identify the module interface
unit source code and translate it (produce and discard a module artifact
if useful; or not). And I'm looking for the answers to "where is the
module interface unit source" and "how do I translate it" to be
available in some industry standard tool agnostic form that doesn't
require a running build invocation (but can depend on a prior (partial)
build).

Tom.

Received on 2018-08-31 20:44:26