I mistakenly replied privately to Daniel's email, to which Daniel privately
replied back. From now on, I will use the Reply All option. Very sorry for
the confusion.

https://youtu.be/_LGR0U5Opdg?t=3148

How this example is to be compiled by the build-system after the new
consensus. During the scanning, build-system can not supply the dependency
header-units, as it does not know them beforehand. The scanner will error
out because of the unavailability of the header-unit.


On Wed, Aug 2, 2023 at 6:26 PM Daniel Ruoso <daniel_at_[hidden]> wrote:

> On Wed, Aug 2, 2023, 08:21 Hassan Sajjad <hassan.sajjad069_at_[hidden]>
> wrote:
>
>> I think all of the header-units consumer relationships need to be
>>> specified upfront so that the build system can pass them on the command
>>> line to the scanner.
>>
>>
> The problem with that approach is that it means the list becomes an input
> to the scan, which means changing the list forces a rescan of all
> translation units.
>
> If, otoh, the scanner discovers it, that goes away.
>
> So, all of these need to be specified in the metadata file. If the user
>>> has to manually specify then it could be tedious, else how it could be
>>> auto-generated.
>>
>>
> There's no way to identify whether a header is importable or not just by
> its contents. The definition of which headers are importable has to be
> authored by a human.
>
> And, in one configuration, a file might import a header-unit, in another,
>>> it might not.
>>
>>
> What is the use case for that?
>
> But, the conversation in Varna did include a provision for an overlay
> mechanic such that the user may declare headers installed in the system as
> importable.
>
> Would it be possible for you to share more details?
>>
>>
> Please take a look at the PR[1] in the modules ecosystem TR draft for more
> details.
>
> Daniel
>
> [1] https://github.com/cplusplus/modules-ecosystem-tr/pull/26
>
>>