[Tooling] [isocpp-modules] Round2: Path to modules with old bad build systems
Michael Spencer
bigcheesegs at gmail.com
Tue Mar 5 23:22:55 CET 2019
On Tue, Mar 5, 2019 at 12:59 PM Gabriel Dos Reis via Modules <
modules at lists.isocpp.org> 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.
>
Can you provide an example of what a reasonable output would be for the
following?
// ================= interface.cppmi
export module i;
export void foo() {
// ...
}
// ================= user.cpp
import i;
void a() {
foo();
}
// =================
For reference clang (should) output the following:
#pragma clang module build i
# 1 "<built-in>"
# 1 "interface.cppmi"
export module i;
export void foo();
#pragma clang module endbuild /*i*/
# 1 "<built-in>"
# 1 "user.cpp"
import i;
void a() {
foo();
}
It currently actually outputs <<<INVALID BUFFER>> instead of the interface
because it comes from a pcm (BMI), but it works for header imports.
- Michael Spencer
>
>
> *From:* Mathias Stearn <redbeard0531+isocpp at gmail.com>
> *Sent:* Tuesday, March 5, 2019 12:47 PM
> *To:* Ben Boeckel via Modules <modules at lists.isocpp.org>
> *Cc:* Ben Craig <ben.craig at ni.com>; Gabriel Dos Reis <gdr at microsoft.com>;
> WG21 Tooling Study Group SG15 <tooling at open-std.org>; Nathan Sidwell <
> 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> 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.
> _______________________________________________
> Modules mailing list
> Modules at lists.isocpp.org
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/03/0167.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20190305/45ecc4e0/attachment.html
More information about the Tooling
mailing list