It is not clear to me why we would want to have this apply to header unit. By the definitions, they are not modules. They don't have names other than the name of the header or header file. They don't provide anything other than their content as a whole. The only dependencies they have are exactly the same that their headers or header files have and therefore can be extracted via the usual pre-processing scan. Why would their BMIs be required for dependencies?

-- Gaby

| -----Original Message-----
| From: Modules <modules-bounces_at_[hidden]> On Behalf Of Boris
| Kolpackov
| Sent: Wednesday, April 10, 2019 3:15 AM
| To: Ben Boeckel via Modules <modules_at_[hidden]>
| Cc: brad.king_at_[hidden]; WG21 Tooling Study Group SG15
| <tooling_at_[hidden]>; Ben Boeckel <ben.boeckel_at_[hidden]>
| Subject: Re: [isocpp-modules] Dependency format with module details
| implementation
|
| Ben Boeckel via Modules <modules_at_[hidden]> writes:
|
| > Is there anything folks would like me to discuss?
|
| I am trying to understand if/how this will help/work with header
| units and include translation.
|
| My understanding is this dependency information will be based
| on the preprocessed output. However, header unit BMIs have to
| be made available during preprocessing (because they may export
| macros that could affect further preprocessing). My recollection
| from earlier discussions is that while this format may (must?)
| include the dependency information for header units (and take
| into account include translation), it does not try to solve/help
| with the "how are those header unit BMIs made available" problem.
|
| If this understanding is accurate, then the question is how do
| we handle header units? Several options have been proposed:
|
| 1. Use a dynamic module mapper to supply these BMIs as pre-
| processing progresses. This is the GCC's Module Mapper
| approach (P1184).
|
| 2. Assume the compiler takes care of it somehow. As to how,
| there were several ideas:
|
| b) The compiler builds the header unit BMIs on the fly in
| some kind of a cache.
|
| a) The compiler still preprocesses the header emulating
| the import semantics (macro isolation, etc).
|
| 3. Have all the header units pre-compiled at some kind of a
| pre-build step (since they can import each other, their
| dependency information will have to be pre-specified).
|
| 4. Anything I am missing/forgetting?
|
| To me only the first approach (dynamic mapper) seems like a
| realistic option for a general-purpose build system (other
| options may be appropriate for compiler or codebase-specific
| build systems). But if we go the mapper approach, then it's
| not clear why use this dependency extraction functionality --
| as part of answering the mapping questions the build system
| already knows all the dependencies.
|
| So the conclusion I seem to be arriving at is while potentially
| useful for other cases/tools, this functionality won't help a
| general-purpose build system.
|
| Thoughts?
| _______________________________________________
| 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%7C40744f8039344c66d27808d6bd9d59cf%7C72f988bf86
| f141af91ab2d7cd011db47%7C1%7C0%7C636904880867209779&amp;sdata=
| AQ%2B95imqB9C4WgOOXErjBQqy31vn%2FfImkpw4B0iPIDw%3D&amp;reser
| ved=0
| Link to this post:
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is
| ocpp.org%2Fmodules%2F2019%2F04%2F0367.php&amp;data=02%7C01%7C
| gdr%40microsoft.com%7C40744f8039344c66d27808d6bd9d59cf%7C72f988bf
| 86f141af91ab2d7cd011db47%7C1%7C0%7C636904880867209779&amp;sdat
| a=mDpZyBe7CYVTWc3333nJ%2FCAJI8XHUBhH65ks5G5Emcs%3D&amp;reser
| ved=0