On Tue, Mar 5, 2019 at 12:59 PM Gabriel Dos Reis via Modules <
modules_at_[hidden]> 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_[hidden]>
> *Sent:* Tuesday, March 5, 2019 12:47 PM
> *To:* Ben Boeckel via Modules <modules_at_[hidden]>
> *Cc:* Ben Craig <ben.craig_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>;
> WG21 Tooling Study Group SG15 <tooling_at_[hidden]>; Nathan Sidwell <
> nathan_at_[hidden]>
> *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_[hidden]> 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_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/03/0167.php
>