For an #include you can run the preprocessor exactly. For an import you, at
least in theory, need either know how the bmi was created, or do the
processing implicitly and then import the BMI. If I understand correctly,
this is why clang will track the flags used in implicit bmi creation,
because they might change and make the BMI incorrect.

On Wed, Mar 6, 2019 at 4:07 PM Gabriel Dos Reis via Modules <
modules_at_[hidden]> wrote:

> Isn't the situation exactly the same if the 'import's are replaced with
> '#include's?
>
> -- Gaby
>
> | -----Original Message-----
> | From: Modules <modules-bounces_at_[hidden]> On Behalf Of Nathan
> | Sidwell
> | Sent: Wednesday, March 6, 2019 1:01 PM
> | To: modules_at_[hidden]; Mathias Stearn
> | <redbeard0531+isocpp_at_[hidden]>
> | Cc: boris_at_[hidden]; brad.king_at_[hidden]; WG21 Tooling Study
> | Group SG15 <tooling_at_[hidden]>; Ben Boeckel
> | <ben.boeckel_at_[hidden]>
> | Subject: Re: [isocpp-modules] [Tooling] Dependency information for
> module-
> | aware build tools
> |
> | On 3/6/19 3:01 PM, Mathias Stearn wrote:
> | >
> | >
> | > On Wed, Mar 6, 2019 at 10:18 AM Nathan Sidwell <nathan_at_[hidden]
> | > <mailto:nathan_at_[hidden]>> wrote:
> | >
> | > Yes, a BMI is required for a header import. Textually including
> the
> | > header import's original header file is not equivalent.
> | >
> | >
> | > It won't be required for the scan stage will it? If it is, there is a
> | > bootstrapping problem because there is no good way to figure out which
> | > order to build the header-unit BMIs in if they import other
> | > header-units. I've been assuming that the scan stage will be able to
> | > just temporarily mask off the defines and replace them with the correct
> | > ones for the header-unit while scanning a file, so that scanning has no
> | > generated dependencies.
> |
> | As header units export #defines, which can go on to determine the path
> | of conditional inclusion, you have to decide:
> |
> | a) if you want precise scanning, you need the header units at scan time
> |
> | b) if you're ok with imprecise scanning (getting false positives). But
> | you need something other than the C++ preprocessor[*]. Of course you
> | have to deal with things like:
> |
> | import "config";
> | #if MACRO_MAYBE_FROM_IMPORT
> | import linux;
> | #else
> | import windows;
> | #endif
> |
> | Only one of those imports is needed and (very likely) building the
> | unneeded one will fail. So you build both, but don't abort the build
> | until a true dependency needs a failed module.
> |
> | nathan
> |
> | [*] make some assumptions (define some requirements) about code
> | formatting and recursively execute;
> | grep import -> import list
> | grep '#include' -> includes to recursively process
> |
> | --
> | Nathan Sidwell
> | _______________________________________________
> | Modules mailing list
> | Modules_at_[hidden]
> | Subscription:
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is
> | ocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;data=02%7C01%7Cgd
> | r%40microsoft.com%7Cf0e94e4aa98146ac173508d6a276dbfc%7C72f988bf86
> | f141af91ab2d7cd011db47%7C1%7C0%7C636875028725148958&amp;sdata=
> | 5y610xUBIm6%2BR1YbjhYS2R038iMEK%2BUpaTPjY0X3SBU%3D&amp;reserve
> | d=0
> | Link to this post:
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is
> | ocpp.org%2Fmodules%2F2019%2F03%2F0192.php&amp;data=02%7C01%7C
> | gdr%40microsoft.com%7Cf0e94e4aa98146ac173508d6a276dbfc%7C72f988bf
> | 86f141af91ab2d7cd011db47%7C1%7C0%7C636875028725148958&amp;sdat
> | a=%2FPosH%2FG3%2BWRCHnq2PqXMYFhp5R%2BiA7vJgJJNUbOWqkE%3D&a
> | mp;reserved=0
> _______________________________________________
> 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/0193.php
>