> Rather, I meant a processing where work is duplicated, as if header
> files, with special modifications - not all expressible in Standard C++

My original post includes examples, and the examples use #pragmas to indicate the bounds of the textually included module. I think the pragmas give sufficient information to downstream compilers to get conforming isolation.

Here are those examples reproduced...

Example input:
// ~/all_libs/my_lib/data.cpp
// interface + implementation
export module data;
export int x;

// ~/all_libs/my_lib/foo.cpp
// interface
export module foo;
import data;
export int func();

// ~/all_libs/my_lib/foo_impl.cpp
// implementation
module foo;
int func() {return x;};

// ~/my_exe/bar.cpp
// non-modular
import foo;
int main() {return func();}

Example invocation 1 (give me object files for all implementations):
my_compiler --strawman-slow-modules -I ~/all_libs/my_lib bar.cpp -o bar.o
my_compiler --strawman-slow-modules -I ~/all_libs/my_lib ~/all_libs/my_lib/foo_impl.cpp -o ~/all_libs/my_lib/foo_impl.o
my_compiler --strawman-slow-modules -I ~/all_libs/my_lib ~/all_libs/my_lib/data.cpp -o ~/all_libs/my_lib/data.o

Example invocation 2 (give me textually processed files for tooling / distribution):
my_compiler --strawman-slow-modules -E -I ~/all_libs/my_lib bar.cpp -o bar.i
my_compiler --strawman-slow-modules -E -I ~/all_libs/my_lib ~/all_libs/my_lib/foo_impl.cpp -o ~/all_libs/my_lib/foo_impl.i
my_compiler --strawman-slow-modules -E -I ~/all_libs/my_lib ~/all_libs/my_lib/data.cpp -o ~/all_libs/my_lib/data.i

Example outputs:
// ~/my_exe/bar.i
#pragma strawman-module begin(foo)
export module foo;
#pragma strawman-module begin(data)
export module data;
export int x;
#pragma strawman-module end(data)
export int func();
#pragma strawman-module end(foo)
int main() {return func();}

//~/all_libs/my_lib/foo_impl.i
module foo;
#pragma strawman-module begin(foo)
export module foo;
#pragma strawman-module begin(data)
export module data;
export int x;
#pragma strawman-module end(data)
export int func();
#pragma strawman-module end(foo)
int func() {return 42;};

//~/all_libs/my_lib/data.i
export module data;
export int x;

> -----Original Message-----
> From: Modules <modules-bounces_at_lists.isocpp.org> On Behalf Of Gabriel
> Dos Reis via Modules
> Sent: Monday, March 4, 2019 12:16 PM
> To: modules_at_[hidden]
> Cc: Gabriel Dos Reis <gdr_at_microsoft.com>; WG21 Tooling Study Group SG15
> <tooling_at_[hidden]>; Nathan Sidwell <nathan_at_acm.org>
> Subject: [EXTERNAL] Re: [isocpp-modules] Round2: Path to modules with old
> bad build systems
>
> When I said “glorified header files”, I didn’t mean literally textual inclusion of
> the primary module interface file - obviously, that can’t work for a variety of
> reasons. Rather, I meant a processing where work is duplicated, as if header
> files, with special modifications - not all expressible in Standard C++ - for the
> semantics of declarations: the global module fragment stays unmodified;
> macro isolation applies; non-template function definitions are erased to non-
> defining declarations; class definitions are retained; template definitions are
> retained; constexpr variables are made inline; module boundaries are
> enforced during lookup and overload resolutions, thanks to module
> ownership; etc.
>
>
> — Gaby
>
> > On Mar 4, 2019, at 5:02 AM, Ben Craig <ben.craig_at_ni.com> wrote:
> >
> > I do mean textual inclusion, though I can be convinced otherwise. Textual
> inclusion (with extra generated pragmas) should make it much easier to keep
> tools like distcc and cppcheck happy in the short term. I suspect that those
> tools don't want to crack open a BMI to figure out which other BMIs need to
> be found.
> >
> > Tools that (think they can) parse C++ will still need to understand these
> pragmas in order to provide the right macro, visibility, and reachability
> behaviors, so some work will still be required on their part, but at least they
> won't need to understand new binary formats.
> >
> > That said, Mathias Stearn raised an interesting point... I'm not sure how
> onerous it is for implementations to drop non-macro symbols. A pragma
> marking the end of a module gives the implementation the information it
> needs, but that doesn't mean it's easy to remove elements from the data
> structure. The BMI model likely makes it easier to never add private symbols
> in the first place.
> >
> >> -----Original Message-----
> >> From: Nathan Sidwell <nathanmsidwell_at_gmail.com> On Behalf Of Nathan
> >> Sidwell
> >> Sent: Monday, March 4, 2019 8:51 AM
> >> To: modules_at_lists.isocpp.org; Ben Craig <ben.craig_at_ni.com>; WG21
> >> Tooling Study Group SG15 <tooling_at_[hidden]>
> >> Subject: [EXTERNAL] Re: [isocpp-modules] Round2: Path to modules with
> >> old bad build systems
> >>
> >>> On 3/2/19 1:03 PM, Ben Craig wrote:
> >>>
> >>> Some quick notes on this implementation strategy:
> >>> * Uses TEXTUAL inclusion
> >>> * Compiler assumes that the build system knows nothing of BMIs
> >>> * Compiler needs to be able to do module mapping with minimal input
> >>> from users.
> >>
> >> Do you literally mean textual inclusion or do you really mean
> >> dynamically produce an internal-only BMI object?
> >>
> >> nathan
> >>
> >> --
> >> Nathan Sidwell
> > _______________________________________________
> > Modules mailing list
> > Modules_at_lists.isocpp.org
> > Subscription:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.p
> > rotection.outlook.com_-3Furl-3Dhttp-253A-252F-252Flists.isocpp.org-252
> > Fmailman-252Flistinfo.cgi-252Fmodules-26amp-3Bdata-3D02-257C01-
> 257Cgdr
> > -2540microsoft.com-257C06344e156b854092450208d6a0b27795-
> 257C72f988bf86
> > f141af91ab2d7cd011db47-257C1-257C0-257C636873085702512645-26amp-
> 3Bsdat
> > a-3DqM-252FmOqRVA81hUKZiOUJOotig4lYc33qg7p8eU8EZ84w-253D-
> 26amp-3Breser
> > ved-
> 3D0&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8m
> ub
> > 81SfUi-
> UCZRX0Vl1g&m=foGjp3Y7BgyCpV4GCc28_iHNymI4CwC7WyBueOEKhIg&s=7
> AHr
> > bCAPZXwST0966zYOVw5PaCbyG_5HCfLUxSVZD5M&e=
> > Link to this post:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.p
> > rotection.outlook.com_-3Furl-3Dhttp-253A-252F-252Flists.isocpp.org-252
> > Fmodules-252F2019-252F03-252F0120.php-26amp-3Bdata-3D02-257C01-
> 257Cgdr
> > -2540microsoft.com-257C06344e156b854092450208d6a0b27795-
> 257C72f988bf86
> > f141af91ab2d7cd011db47-257C1-257C0-257C636873085702523047-26amp-
> 3Bsdat
> > a-3D6auBsrmwiCZ5IocDsVd5d1DzgW6rj2mMvHp0Lw9IxHQ-253D-26amp-
> 3Breserved-
> >
> 3D0&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8m
> ub81Sf
> > Ui-
> UCZRX0Vl1g&m=foGjp3Y7BgyCpV4GCc28_iHNymI4CwC7WyBueOEKhIg&s=4
> qUR77B2
> > KzA38drmZlFnxT7Pids_K37XfpnQTkICHwg&e=
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__lists.isocpp.org_mailman_listinfo.cgi_modules&d=DwIGaQ&c=I_0YwoK
> y7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=foGjp3Y7BgyCpV4GCc28_iHNymI4CwC7WyBueOEKhIg&s=w
> 1TXxsPRl2AwrIcaeEs7knUP6Zlzp3BSwLwvbUU_EMI&e=
> Link to this post: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__lists.isocpp.org_modules_2019_03_0121.php&d=DwIGaQ&c=I_0YwoKy
> 7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=foGjp3Y7BgyCpV4GCc28_iHNymI4CwC7WyBueOEKhIg&s=4
> 50i0ST2ScefIX8Zu9sgpbNTS_Q6F-oJtseqpG8zWNk&e=