> If the header themselves identify if they're importable or not it
means the build system needs to scan all headers (inside and outside
the project, directly and transitively included) for that keyword in
order to decide if a BMI needs to be produced or not. Particularly,
that has to happen before the module dependency scanning, because a
header becoming importable changes the overall shape of the dependency
graph.

Xmake now has some handling of headerunits

1. first scan the module dependency graph
2. get all the stl/user headerunits from there and try to find their real
paths from the project and system directories.
3. compile the headerunits into bmi
4. build all the modules
5. build all the c/c++ source code and import the headerunits and modules

https://github.com/xmake-io/xmake/blob/8737561ceb4347207db3fca3146a7dbcee02a9a9/xmake/rules/c%2B%2B/modules/xmake.lua#L98
https://github.com/xmake-io/xmake/blob/8737561ceb4347207db3fca3146a7dbcee02a9a9/xmake/rules/c%2B%2B/modules/modules_support/common.lua#L63-L88

Iain Sandoe via SG15 <sg15_at_[hidden]> 于2022年10月13日周四 17:17写道：

>
>
> > On 13 Oct 2022, at 10:01, Daniel Ruoso <daniel_at_[hidden]> wrote:
> >
> > Em qui., 13 de out. de 2022 às 10:41, Iain Sandoe via SG15
> > <sg15_at_[hidden]> escreveu:
> >> I expect that this has been discussed before, and I’ve missed it
> somehow .. but several times during my implementation work on clang, it
> seemed to me that this problem would go away if importable header units
> were required to start with a keyword.
> > ...
> >> Given an expectation that the user has to identify importable header
> units somehow, doing it in the source seems to me to be the neatest
> solution.
> >> what did I miss?
> >
> > If the header themselves identify if they're importable or not it
> > means the build system needs to scan all headers (inside and outside
> > the project, directly and transitively included) for that keyword in
> > order to decide if a BMI needs to be produced or not. Particularly,
> > that has to happen before the module dependency scanning, because a
> > header becoming importable changes the overall shape of the dependency
> > graph.
>
> OK, I get that point…
>
> > If, OTOH, between the package management and the build system, that
> > information is available before-hand, and the list of importable
> > headers is provided before the dependency scanning, then the
> > dependency scanning knows to treat that include statement as an import
> > and then the header unit will have its dependencies scanned
> > independently.
>
> … but, one might equally argue for any part of the dependency graph to be
> pre-set by the user would reduce the load on dependency determination.
>
> Iain
>
> > Currently, I am of the opinion that identifying the importable headers
> > must be handled in metadata, before the build system even starts
> > anything.
> >
> > daniel
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

-- 
_______________________________________________
Ruki Wang
https://xmake.io
https://github.com/waruqi