From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by sourceware.org (Postfix) with ESMTPS id C9CA9385840A for ; Sat, 29 Jul 2023 14:25:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C9CA9385840A 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-xf2d.google.com with SMTP id 6a1803df08f44-63cf3dcffe0so18352256d6.1 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=dECwRiB4LpDQNLPyKR5qcP5T+1LiTd/Wk51pwXwIqDzQfEDVG2LyC12cFBMOS3Vfse mQjJxBCC4pHHWwyBYqQd6HVxibbKeuT+9OHTtzNsK7B6hR5RTQ1aUQgmbqotGYUEGmr3 qLj7MyQ/h5XZq2BqOYq5tgTPPSx5qFSkFsGbggh34Rh99jQK72XEZLpUbE66RvXhtia7 EpllqmYOST41/cvElXTZQMDeAZ6amBE876oQSD7J9aAEqTU4TcDpWFRI2s3giBKIiFrg xq7NsXhhWOvRMNaGZODB0qdRMOBVN/pPAIX6p6+82EnMnZlsA/maje7iccAiYlkzzqhW VfNw== X-Gm-Message-State: ABy/qLaSxU7460vn1viNYqTl6b57LBa1NB5lZ5jPDkhYEhP2XauADu/N vpvvxV1N3V9FyPnVl7KHM55PnQ== 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=-4.9 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=ham 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