I think that textual inclusion of modules could indeed have worse build throughput than headers. I think the worst case will be when the application is modularized, but depends on non-modular libraries. If I pull in a dozen of my own modules in a TU, and each of those #include's <boost/log.hpp> (for example), then I can imagine the build times getting nasty.

I don't see that as a showstopper for textual inclusion, but I do see it as strong motivation to improve the build system.

> -----Original Message-----
> From: Modules <modules-bounces_at_[hidden]> On Behalf Of Boris
> Kolpackov
> Sent: Sunday, March 3, 2019 8:34 AM
> To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
> Cc: modules_at_[hidden]
> Subject: [EXTERNAL] Re: [isocpp-modules] [Tooling] Round2: Path to
> modules with old bad build systems
>
> Ben Craig <ben.craig_at_[hidden]> writes:
>
> > The scheme I have in mind would result in no build throughput
> > improvements with the old bad build systems, but I think it would
> > still provide the isolation benefits of modules and be conforming.
>
> I wonder if it could result in worse build throughput compared to headers,
> thought?
>
> To be conforming, not only the importing TU will have to be isolated from any
> macros defined by the module interface, but the module intreface will have
> to be isolated from any macros definited by the importing TU (whether it
> should also be isolated from macros defined on the command line is an
> interesting question, BTW). And this isolation will have to happen recursively,
> for modules imported by module interfaces.
>
> Now consider a TU that imports a bunch of modules which in turn each
> import a bunch more and all of them include some common header, say
> <functional>. The above isolation rules mean that each of those "module
> interface fragments" (for the lack of better term) will include their own full
> copy of <functional> (because the include guards will not be defined; how
> this feature interact with #pragma once is an intersting question, BTW).
>
> Note also that the same kind of duplication applies to the module interfaces
> themselves: if a TU imports a bunch of modules which in turn each import
> the same module, its interface fragment will be duplicated as well.
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__lists.isocpp.org_mailman_listinfo.cgi_modules&d=DwICAg&c=I_0YwoKy
> 7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=YXXTk8d75Zr6h9K2dme2973HuosMHH3b2mD_yNeyXME&s
> =J982imERoSrujnHvHfhqK5vBzntmiYNb77qtZk-5nxk&e=
> Link to this post: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__lists.isocpp.org_modules_2019_03_0116.php&d=DwICAg&c=I_0YwoKy7
> z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=YXXTk8d75Zr6h9K2dme2973HuosMHH3b2mD_yNeyXME&s
> =ke4hdwlQm3mOm7BtmTvaPvjt_bkRaKahyAHK3XO_ysQ&e=