From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by sourceware.org (Postfix) with ESMTPS id 52E453858C83 for ; Fri, 22 Apr 2022 16:05:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52E453858C83 Received: by mail-qv1-xf2c.google.com with SMTP id h13so6370789qvr.2 for ; Fri, 22 Apr 2022 09:05:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=JvGqfCj6w5YDvZblap4DwtR7caGwGinNho1j6RnVT0k=; b=XZsdjNGHiNorXnkzaQDmpycZ0iF6NtUOtz7OD7GdPIJZOUfnwIilUxGbue1jTkC7AJ duMfOTogQ5GRwHNLPeVkdqk63nhZAFZWaJXFypIiBRSBMg0yhrQySLnSc5VMYaqX8yua tKo7JQ94EOgCKTR2h3PHDzzKeecczAda43IT2Zw0Akzs0YaM5VD7GtYO0BcZQbs2iaYe EmQIe/kL/FGYJMQtSiyUGauXyDkttB8A149ipILV3kmujH7zvM3/EWx7znsu1cKVGRqG gVZI+AdlbvvM+zgbuaopshyvcCM845a7yvzEiB8ATXWBO5Z33KTjDG4Z1/suOuY/1o7z OWGw== X-Gm-Message-State: AOAM533UsvC+/0EPTq0L/SQqdPLeCj06OiHBHBJYq4bgwnLCPEr/VlEh 5k8ve7gM7PlltCixtr+0QZspKJdmPtDrzO97 X-Google-Smtp-Source: ABdhPJz0d37jdM6GaFUbzWVMzA3dIEnzIkaxzBU5+0Ilkr1E+hxLK4lbgKQpgS1o2hndhf/pp6GEdg== X-Received: by 2002:a05:6214:c26:b0:446:63cb:35eb with SMTP id a6-20020a0562140c2600b0044663cb35ebmr3948312qvd.63.1650643542558; Fri, 22 Apr 2022 09:05:42 -0700 (PDT) Received: from localhost (cpe-142-105-146-128.nycap.res.rr.com. [142.105.146.128]) by smtp.gmail.com with ESMTPSA id p3-20020a05620a15e300b0069e5b556f75sm1059634qkm.5.2022.04.22.09.05.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 09:05:42 -0700 (PDT) Date: Fri, 22 Apr 2022 12:05:41 -0400 From: Ben Boeckel To: Boris Kolpackov Cc: gcc@gcc.gnu.org Subject: Re: [modules] Preprocessing requires compiled header unit modules Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.1.5 (2021-12-30) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2022 16:05:44 -0000 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 get accurate dependency information, then something > has to give. 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 not being able to perform `cl.exe *.cpp` anymore should be the least of people's worries on the recent megathread because the following tools are all unsuitable for C++ with header units without major overhauls (alphabetical): - autoconf/automake - cmake - gn - gyp - make (not GNU make, though even that requires some active involvement via the socket communications) - meson - ninja I'm sure there are many more in use out there. > In this example, if you treat import of header-unit.hpp as > include, you will get incorrect dependency information. > > So to make this work correctly we will need to re-create the > macro isolation semantics of import for include. I'm aware. This is what I alluded to with "CPP state is probably not easy". > Even if we manage to do this, there are some implications I > am not sure we will like: the isolated macros will contain > inclusion guards, which means we will keep re-scanning the > same files potentially many many time. Here is an example, > assume each header-unitN.hpp includes or imports : Note that scanning each module TU only happens once. Header units might just get *read* in the course of scanning other units. And headers are read multiple times already over the lifetime of the build, so we're not making things worse here. I wonder if we had had a modularized stdlib which landed with modules if header units would have been a thing in the first place… --Ben