Date: Wed, 10 Apr 2019 12:14:33 +0200
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?
> 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?
Received on 2019-04-10 12:14:42