[cfe-dev] Modules TS: any alternatives?
cfe-dev at lists.llvm.org
Tue Apr 30 12:19:44 PDT 2019
Good to know!
30.04.2019, 21:03, "David Blaikie" <dblaikie at gmail.com>:
> On Tue, Apr 30, 2019 at 6:01 AM via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> Hi folks!
>> Did anybody ever considered possible alternatives to modules TS?
> A lot of discussion and design went into the modules TS and variants, yes.
>> I mean per current modules TS, it looks like compiler should be a build system at same time, which is unusual..
> The characterization of the compiler as a build system is one that
> gets people a bit tetchy - though the underlying concerns about
> transparency of parallelism, etc, are important to consider.
> The directions being pursued by both Clang and GCC are intended to
> avoid having the compiler orchestrate the work - to ensure that
> parallel and distributed build systems can handle this sort of thing.
> Clang already has two modes - one it's had a lot longer than Modules
> TS (& in part was some of the inspiration for the TS) that is sort of
> a nested build system where the compiler does orchestrate the
> building, storage, and retrieval of the binary representation of
> modules (this is used in XCode/on MacOS today & has been for a while
> now). But also one where the compiler does none of this and relies on
> the build system to have complete, explicit knowledge of dependencies,
> to generate dependencies first, and to pass them to compilations that
> need them (this is used at Google & has been for a few years)
> But there is a desire for something in between - for build systems
> that don't have total knowledge, but want greater parallelism/build
> transparency than the implicit module can provide. Folks on Clang
> (Apple folks have built a prototype import scanner of sorts that could
> be run up-front to discover the module dependency graph) and GCC (the
> GCC Modules TS prototype includes a callback service where the
> compiler queries an arbitrary oracle (possibly implemented by the
> build system) to state its module needs on-the-fly) are working on
> approaches that provide this.
> - Dave
>> Stepan Dyatkovskiy
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
More information about the cfe-dev