From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) by sourceware.org (Postfix) with ESMTPS id 21287385840F for ; Mon, 25 Apr 2022 11:34:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21287385840F Received: by mail-qt1-x82a.google.com with SMTP id v2so3368572qto.6 for ; Mon, 25 Apr 2022 04:34:37 -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:in-reply-to:user-agent; bh=Q+HN/fAncWPFh2Uxfu1OrmIx/5p4SQbLgYy0yiW13fk=; b=Nf5faESnlLMLUQ2mpQPYr9txVoeQx4J6U6d87ojjHA/FJMcgzKw8PCLV7h5vf/B4Q4 rr463vOS9PTKojQUPcGpYIQTPylPawH+l5c1y8a6j3PFiYBkxryXnfdWqvKRd50YRTgE xoPel79BH4hP7wQQ5Ut5sc48b3KEdg4Y18EBFpNIr+lBp/qLBV/z2XBPd6LevC78aWVW ky9yz1sgqtEMrtn6VehAQeThOW5WNMgxLERPn1+0uwb+JBN73pJ+aXkxZPBLqSLEQ1t7 QQ7lHnARB4xo9CU9/te+lKwaBh5y+8vJajm9gjNrfNs7A0hEUTxWXjgkFhFey8wbMPad 6JwQ== X-Gm-Message-State: AOAM531/cUYS7BqEH3MPkeq4R2obnKHbN0wI59zotUWAmqnnT0L7dMPG lq7ePBB67hQglB2nNlf83B7USA9U75RWZOgW X-Google-Smtp-Source: ABdhPJwr1JSIiLAEpVYSuTc6KyeoEW/wK0UpRZNALzdKMNmzNnGQLgrqd9eaBz9tMTsJzXtwvvlCLA== X-Received: by 2002:a05:622a:2cb:b0:2f3:646b:54b6 with SMTP id a11-20020a05622a02cb00b002f3646b54b6mr4642553qtx.380.1650886476465; Mon, 25 Apr 2022 04:34:36 -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 v7-20020a379307000000b0069c0a2afc55sm4914666qkd.123.2022.04.25.04.34.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Apr 2022 04:34:35 -0700 (PDT) Date: Mon, 25 Apr 2022 07:34:34 -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 In-Reply-To: User-Agent: Mutt/2.1.5 (2021-12-30) X-Spam-Status: No, score=-2.2 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: Mon, 25 Apr 2022 11:34:38 -0000 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 builds, but is "actively" participating in the build itself. Ninja's `dyndep` is about as close one can be to the edge IMO. `make` is potentially active because of its behavior around `include` of output files, but this is a niche feature. > 3. I agree some build systems may require "major overhauls" to > support header units via the module mapper. I would like this > not to be the case, but so far nobody has implemented an > alternative (that I am aware of) that is correct and scalable > and I personally have doubts such a thing is achievable. One the compilers can scan headers, CMake should be able to do it. MSVC is the closest right now (though the name it wants for any given header usage site is currently an issue). > Ben Boeckel writes: > > 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 am not sure I follow. Say we have 10 TUs each include or import > 10 headers each of which includes . If we use include, > then when scanning each of these 10 TUs we have to scan > once (since all the subsequent includes are suppressed by include > guards). So total of 10x1=10 scans of for the entire > build. > > Now if instead of include we use import (which, during the scan, is > treated as include with macro isolation), we are looking at 10 scans > of for each TU (because the include guards are ignored). > So total of 10x10=100 scans of for the build. > > What am I missing? Ew, indeed. I suppose a sufficiently smart compiler could just encode headers as a "diff" to the preprocessor and symbol state and apply it upon revisiting, but that seems like a high bar (re-reading if it detects a difference in preprocessor state that "matters"). --Ben