Date: Thu, 30 Aug 2018 12:45:04 +0200
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?
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.
A. Joël Lamotte
> 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?
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.
A. Joël Lamotte
Received on 2018-08-30 12:45:43