From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) by sourceware.org (Postfix) with ESMTPS id C6C2E3858C31 for ; Sat, 29 Jul 2023 14:25:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6C2E3858C31 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=kitware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kitware.com Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-63d30b90197so18439876d6.0 for ; Sat, 29 Jul 2023 07:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kitware.com; s=google; t=1690640748; x=1691245548; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=l20S+NRsuth7CR3NBKaTZvUt6NVwvXbmwkTCYssVl0k=; b=Y3L8r1ZU2MadrZyBL4kqqO1AZiKBr4PqmfLXZMUZpwR8dIxx7X4q/bVr5GWuMlnJz2 M54KZ5Gb5pEOnTeET8Eoaw+ZEu5VwHVclVyAPLH+3LR4WHaCu5DNAA5EYfLmDupJGkwU rCVGczMma+mmaZxIddcOZ/ffeWUIoj2eNceyM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690640748; x=1691245548; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=l20S+NRsuth7CR3NBKaTZvUt6NVwvXbmwkTCYssVl0k=; b=DcyALI6T0Tfd/p6IMqKcn1ehthRjOljg6BS3Yx1feHd6Id1RYH0YoqQoHcR/O9tWDN zzCFOwbVkH0p25bUZQqH5FnZMV+ONtJOglr1GMXt6Am2AWFLwB+Y34rj2fKP645KsSh3 6H+ijdxQ+DI13GHkBem8jjW0kb26pcwxKqbeFbvHKj6tlK++01Je4n+99Dp7rIL+v2NC aEz8+3muIVNRgWKQ0xBCGpETVMS5Il1oiopFUTNWRNie134oNn8Ag5XB2kughSDJLjZB Ss1n1q4zlGKndyw5KfKpfi8HNd5CPw2bKN8tpiaR7wp3SzdU8lZDuw5vwVrRyR68J/6z v0+Q== X-Gm-Message-State: ABy/qLY2t9iYGoZzs4kZkzdluIjgLvnbm7qNxL5NmDaVxJfmNwR2xE+A gADTt2mzsJKyO9e7cvys4rSxEw== X-Google-Smtp-Source: APBJJlE6435B2aaJTFosmeApOUF0Zne0xSsL7TK31SBe5r8pmWLN9hSUG2pgwB/s0hy9pPN4EP87UA== X-Received: by 2002:a0c:f783:0:b0:63c:e700:d38b with SMTP id s3-20020a0cf783000000b0063ce700d38bmr5465866qvn.29.1690640748053; Sat, 29 Jul 2023 07:25:48 -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 r2-20020a0cb282000000b00626362f1bf1sm2094748qve.63.2023.07.29.07.25.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Jul 2023 07:25:46 -0700 (PDT) Date: Sat, 29 Jul 2023 10:25:45 -0400 From: Ben Boeckel To: Jason Merrill Cc: Nathan Sidwell , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, gcc@gcc.gnu.org, brad.king@kitware.com Subject: Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies Message-ID: References: <20230625163610.GC270821@farprobe> <29600358-9421-cbe3-92b6-ab77a1a715d1@redhat.com> <20230719000144.GA1034956@farprobe> <80a2e5b6-0580-c3f5-cb75-c8795ebabceb@acm.org> <20230720004723.GA1159121@farprobe> <61774849-b8e5-fb9e-2e30-d6b6cee08859@acm.org> <25ec1e77-fffd-1f39-c797-4a9ba982b22d@acm.org> <8299af0b-f648-3a4b-83f6-86b9191d20c9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8299af0b-f648-3a4b-83f6-86b9191d20c9@redhat.com> User-Agent: Mutt/2.2.9 (2022-11-12) X-Spam-Status: No, score=-3.0 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,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Jul 27, 2023 at 18:13:48 -0700, Jason Merrill wrote: > On 7/23/23 20:26, Ben Boeckel wrote: > > Sure, *CMake* knows them, but the *build tool* needs to be told > > (typically `make` or `ninja`) because it is what is actually executing > > the build graph. The way this is communicated is via `-MF` files and > > that's what I'm providing in this patch. Note that `ninja` does not > > allow rules to specify such dependencies for other rules than the one it > > is reading the file for. > > But since the direct imports need to be rebuilt themselves if the > transitive imports change, the build graph should be the same whether or > not the transitive imports are repeated? Either way, if a transitive > import changes you need to rebuild the direct import and then the importer. I suppose I have seen enough bad build systems that don't do everything correctly that I'm interested in creating "pits of success" rather than "well, you didn't get thing X 100% correct, so you're screwed here too". The case that I think is most likely here is that someone has a "superbuild" with 3 projects A, B, and C where C uses B and B uses A. At the top-level the superbuild exposes just "make projectA projectB projectC"-granularity (rather than a combined build graph; they may use different build systems) and then users go into some projectC directly and forget to update projectB after updating projectA (known to all use the same compiler/flags so that CMI sharing is possible). The build it still broken, but ideally they get notified in some useful way when rebuilding the TU rather than…whatever ends up catching the problem incidentally. > I guess it shouldn't hurt to have the transitive imports in the -MF > file, as long as they aren't also in the p1689 file, so I'm not > particularly opposed to this change, but I don't see how it makes a > practical difference. Correct. The P1689 shouldn't even know about transitive imports (well, maybe from header units?) as it just records "I saw an `import` statement" and should never look up CMI files (indeed, we would need another scanning step to know what CMI files to create for the P1689 scan if they were necessary…). --Ben