Date: Thu, 13 Oct 2022 17:19:49 +0800
I just feel the feature of header unit becomes somehow meaningless if we can't import the original headers without modification... I thought the header unit was designed for compatibility and the named modules are the desired direction.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Iain Sandoe via SG15 <sg15_at_[hidden]>
Send Time:2022 Oct. 13 (Thu.) 17:17
To:Daniel Ruoso <daniel_at_[hidden]>
Cc:Iain Sandoe <iain_at_[hidden]>; sg15 <sg15_at_[hidden]>
Subject:Re: [SG15] Header units again.
> 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
Thanks,
Chuanqi
------------------------------------------------------------------
From:Iain Sandoe via SG15 <sg15_at_[hidden]>
Send Time:2022 Oct. 13 (Thu.) 17:17
To:Daniel Ruoso <daniel_at_[hidden]>
Cc:Iain Sandoe <iain_at_[hidden]>; sg15 <sg15_at_[hidden]>
Subject:Re: [SG15] Header units again.
> 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
Received on 2022-10-13 09:19:54