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
Hi,
I'm looking to update my patch which implements P1689[1] for GCC. I
originally wrote this back in February 2019 at Kona for a proof of
concept[2], but never really got the time to delve back in until now.
I'd like to get header units implemented prior to submitting it as it
will be an importan
12 matches
Mail list logo
