From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) by sourceware.org (Postfix) with ESMTPS id ACE943858C2D for ; Sat, 29 Jul 2023 14:25:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACE943858C2D 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-xf2a.google.com with SMTP id 6a1803df08f44-63d30b90197so18439866d6.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=jk9nJnJ68CXa+NIeUMLx5J7BxKLPK6qoAqMRQ7HzjT0JiaNNGhVQt/Vbpai5hpc3GQ cNDkT160wZjDjjI4D9Fd4MqZhaqW0RV2vnRHY8kdQ0qpNsmY8tHkRkl2I7YbvvNR7J27 /MUzVbenoVO6+3MS8rQc9iTB9kGlCjQzjGX1tu80FGZkosytN9q86JX47HgeKb8NQLUh N/C8D4C1c+L/b/52vwRjrx0fUvs7OnczWZIuObN6TXtZamtN/+GqkaX+rv681tUFI9zU oAbo84dikXmRyR0GcKl7fBaruWXYtLPpJV375cGrzCi0yqVCREZStoOG39Sk44ZZk2L7 w53Q== X-Gm-Message-State: ABy/qLZiQtchnTJbFHrzSyi7BXYweaQsgQAiFG5trN3zSFojcPPaOHyC DGAy6oeTRDAYzTiTO34+3f/0+A== 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