On Mon, Apr 25, 2022 at 11:42:14 +0200, Boris Kolpackov wrote:
> 1. Firstly, this only applies to header units, not named modules.
Correct.
> 2. I am not sure what you mean by "active build executor" (but it
>does sound ominous, I will grant you that ;-)).
One that does more than schedule bu
Ben Boeckel writes:
> If we need to know and have dependencies prepared before we can figure
> out the dependencies for a TU, modules are unsolvable (without an active
> build executor). If C++ implementations are really going to require
> that, then [...] the following tools are all unsuitable f
Iain Sandoe writes:
> The standard has the concept of an “importable header” which is
> implementation-defined.
But it must contain all the C++ library headers:
https://eel.is/c++draft/headers#4
> We could choose that only headers that are self-contained (i.e. unaffected
> by external defines
On Fri, Apr 22, 2022 at 16:08:00 +0200, Boris Kolpackov wrote:
> Ben Boeckel writes:
> > I agree that the header needs to be *found*, but scanning cannot require
> > a pre-existing BMI for that header.
>
> Well, if scanning cannot require a pre-existing BMI but a pre-existing
> BMI is required to
> On 22 Apr 2022, at 15:08, Boris Kolpackov wrote:
>
> Ben Boeckel writes:
>
>> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote:
>>
>>> I don't think it is. A header unit (unlike a named module) may export
>>> macros which could affect further dependencies. Consider:
>>>
>>>
Ben Boeckel writes:
> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote:
>
> > I don't think it is. A header unit (unlike a named module) may export
> > macros which could affect further dependencies. Consider:
> >
> > import "header-unit.hpp"; // May or may not export macro FOO.
> >
> On 21 Apr 2022, at 19:08, Ben Boeckel wrote:
>
> On Thu, Apr 21, 2022 at 18:59:56 +0100, Iain Sandoe wrote:
>> Hi Ben,
>>
>>> On 21 Apr 2022, at 13:05, Ben Boeckel via Gcc wrote:
>>>
>>> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote:
I don't think it is. A header unit
On Thu, Apr 21, 2022 at 18:59:56 +0100, Iain Sandoe wrote:
> Hi Ben,
>
> > On 21 Apr 2022, at 13:05, Ben Boeckel via Gcc wrote:
> >
> > On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote:
> >> I don't think it is. A header unit (unlike a named module) may export
> >> macros which coul
Hi Ben,
> On 21 Apr 2022, at 13:05, Ben Boeckel via Gcc wrote:
>
> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote:
>> I don't think it is. A header unit (unlike a named module) may export
>> macros which could affect further dependencies. Consider:
>>
>> import "header-unit.hpp";
On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote:
> I don't think it is. A header unit (unlike a named module) may export
> macros which could affect further dependencies. Consider:
>
> import "header-unit.hpp"; // May or may not export macro FOO.
>
> #ifdef FOO
> import "header-unit
Ben Boeckel writes:
> However, for header unit modules, it runs into a problem that imported
> header units are required to be compiled and available in the mapper
> while scanning for dependencies.
>
> Example code:
>
> ```c++ # use-header.cpp
> module;
>
> import "header-unit.hpp";
>
> int
11 matches
Mail list logo
