On 08/30/2018 06:45 AM, Klaim - Joël Lamotte wrote:
> On Wed, 29 Aug 2018 at 19:16, Tom Honermann <tom_at_[hidden]> wrote:
>
>> What might such an industry standard approach look like? Here is a sketch of a design:
>>
>> A (set of) module description file(s) that specifies:
>>
>> A map from a module name to the file name for the module interface unit source code. A default naming convention could also be adopted, though we already have two competing conventions (.cppm vs .ixx).
>> A set of requirements for translating the module interface unit source code (for one or more variations or build modes). This includes preprocessor information (include paths, macro definitions, macro undefinitions), and, potentially, language dialect requirements (specified in a generic form and, perhaps, with the ability to customize for specific tools).
>>
>> A method of specifying a path to search for module description files, similar to existing include paths.
>>
>> Note that such module description files need not be statically written and maintained. They could be generated directly by a build system, or as a side effect of compilation. If generated, tools dependent on them would be dependent on a (partial) build having been completed; as is the case today for build systems that generate header files.
>>
> Maybe using URIs instead of paths/files would help implementers have
> the liberty to not necessarilly rely on the filesystem?

That seems reasonable. I'd be a little concerned about use of URIs
accessing network resources, but in that case, you get the trouble you
asked for ;)

> Other than that this sketch does not appear problematic to me.
>
>> Clearly, such a specification falls outside the scope of the C++ standard. However, we could provide a specification in the form of a TS that implementors can adhere to.
>>
>> So, what do you think? Do you agree that there is a problem worth solving here? Is a common specification a feasible solution? Is standardizing such a specification useful and desirable? What requirements should be placed on the design? If you are a compiler or tool implementor, have you already been working on modules support? If so, what approaches have you been considering? Are they captured above? What is your preferred solution?
>>
> Answering as a "power user": I agree that the perspective to have to
> configure all non-buildsystem tools each time I switch projects is
> kind of scary (though we could probably live with
> that). I'm not totally sure if it's worth solving right now, or if it
> is even possible. But less work for us without introducing ambiguities
> is always good.

For some tools, "touchless" support of build systems is essential to
their viability. For example, several static analyzers integrate with a
code base by monitoring a build process and observing compiler
invocations (e.g., Clang's scan-build). This works pretty well in
practice so long as all compiler invocations that produce a source input
(e.g., a module artifact) are actually observed during the build. One
of the new risks posed by modules is that compiler implementors may
distribute precompiled module artifacts (e.g., for the standard library)
that are consumed by a build, but not produced by it. In this case, the
build monitor never observes their construction and therefore doesn't
have the opportunity to produce its own artifacts for later
consumption. This is the status quo for Microsoft's (experimental)
standard library module support. The suggested module description files
would provide a mechanism by which a tool could fall back to source
translation (as opposed to requiring a precompiled module artifact) in
these cases.

Tom.