[Tooling] [isocpp-modules] Round2: Path to modules with old bad build systems
Ben Craig
ben.craig at ni.com
Tue Mar 5 23:24:42 CET 2019
I do care about a single stream, but I no longer care about the #pragma side of things. I thought I cared about it when parseability was still a concern. If a compiler wants to implement single stream via pragmas, then fine. If a compiler wants to implement a single stream as a tar ball, then that is also fine.
The single stream does need to have enough information for a remote machine to be able to generate an object file, just given the compiler toolchain and the stream. A possible implementation would be for the compiler to bundle the main source file and a bunch of module interface source files into the stream. Alternatively, the compiler could do implicit module building and bundle the BMIs and the source file into the stream… but that is putting a bit more work than I would like on the distributing machine.
From: Mathias Stearn <redbeard0531+isocpp at gmail.com>
Sent: Tuesday, March 5, 2019 4:00 PM
To: Gabriel Dos Reis <gdr at microsoft.com>
Cc: Ben Boeckel via Modules <modules at lists.isocpp.org>; Ben Craig <ben.craig at ni.com>; WG21 Tooling Study Group SG15 <tooling at open-std.org>; Nathan Sidwell <nathan at acm.org>
Subject: [EXTERNAL] Re: [isocpp-modules] Round2: Path to modules with old bad build systems
On Tue, Mar 5, 2019 at 3:58 PM Gabriel Dos Reis <gdr at microsoft.com<mailto:gdr at microsoft.com>> wrote:
* If so, then I think we are just using different terms for the same thing. If not, can you explain what is different?
The difference here is the need for new #pragma with special non-standard semantics.
Oh, if that's it, then we are talking about the same thing. The #pragma syntax was just a strawman placeholder. I don't think anyone cares a ton about the format of the single stream, as long as the functionality exists (Ben Craig, please correct me if I am misstating your opinion).
From: Mathias Stearn <redbeard0531+isocpp at gmail.com<mailto:redbeard0531%2Bisocpp at gmail.com>>
Sent: Tuesday, March 5, 2019 12:47 PM
To: Ben Boeckel via Modules <modules at lists.isocpp.org<mailto:modules at lists.isocpp.org>>
Cc: Ben Craig <ben.craig at ni.com<mailto:ben.craig at ni.com>>; Gabriel Dos Reis <gdr at microsoft.com<mailto:gdr at microsoft.com>>; WG21 Tooling Study Group SG15 <tooling at open-std.org<mailto:tooling at open-std.org>>; Nathan Sidwell <nathan at acm.org<mailto:nathan at acm.org>>
Subject: Re: [isocpp-modules] Round2: Path to modules with old bad build systems
On Tue, Mar 5, 2019 at 2:32 PM Gabriel Dos Reis via Modules <modules at lists.isocpp.org<mailto:modules at lists.isocpp.org>> wrote:
Specifically, I don't understand why the compiler would go through the troubles of emitting something like that when it would be simpler to just supply the switch -ftreat-imports-as-glorified-headers. The sources could still be preprocessed and retain the imports, etc.
When you pass -ftreat-imports-as-glorified-headers, can also tell the compiler to just preprocess[1], then take just the output from that and hand it to the compiler again to have it translated to an object file and have it behave the same as if it was working with the original files? If so, then I think we are just using different terms for the same thing. If not, can you explain what is different?
[1] Currently, with gcc and clang, you need to "partially preprocess" using -fdirectives-only or -frewrite-includes because those tools behave differently when compiling TUs that have already been fully preprocessed. I haven't tried doing a similar experiment with MSVC to know how well it handles fully preprocessed files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20190305/da6eced0/attachment-0001.html
More information about the Tooling
mailing list