[Tooling] [isocpp-modules] Dependency information for module-aware build tools

Steve Downey sdowney at gmail.com
Wed Mar 6 22:16:06 CET 2019


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 lists.isocpp.org> 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 lists.isocpp.org> On Behalf Of Nathan
> | Sidwell
> | Sent: Wednesday, March 6, 2019 1:01 PM
> | To: modules at lists.isocpp.org; Mathias Stearn
> | <redbeard0531+isocpp at gmail.com>
> | Cc: boris at codesynthesis.com; brad.king at kitware.com; WG21 Tooling Study
> | Group SG15 <tooling at open-std.org>; Ben Boeckel
> | <ben.boeckel at kitware.com>
> | 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 acm.org
> | > <mailto:nathan at acm.org>> 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 lists.isocpp.org
> | 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 lists.isocpp.org
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/03/0193.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20190306/42b85cff/attachment.html 


More information about the Tooling mailing list