From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by sourceware.org (Postfix) with ESMTPS id B6F1B3858C62 for ; Mon, 24 Jul 2023 00:26:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B6F1B3858C62 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-qk1-x732.google.com with SMTP id af79cd13be357-7659cb9c42aso302601685a.3 for ; Sun, 23 Jul 2023 17:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kitware.com; s=google; t=1690158370; x=1690763170; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=GUBjSah7FAr6cGFjcyljWiuLqoGG1iTaKbFRX8o431w=; b=gh0nlobDtOXjid8TW9Z4hvJz/UMHX9IEnTC5t08Fi1zjCzkdWkgViC+l2yrY2g2cWT l6jMQtsW/OiPp7VguC0qD76eAYOE1zwoZcvVgF5QyonpNU2JTWfnBf2/cmJkd2bI0W48 /qyX+wcP4isbFZ1YG6QsCHmVRQ1XrBgp2z+IM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690158370; x=1690763170; h=user-agent:in-reply-to: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=GUBjSah7FAr6cGFjcyljWiuLqoGG1iTaKbFRX8o431w=; b=kPSRtqRu2OWQq92PhdFYfjtBLxoGvXeCdt5gspdMnl7fNGTnNeinfjjAP6czhQWzbL hNxP6L4E/7KorFUomPtW4sGTKAAITN1H1Rw9nM9Co7UqVuQdTy6/gnjq5K0w5nnpAAE6 Sb22r0Z41o/PiQJP6V0NWDmbS3KGkKIdn346oRIsvhqiFa5Gbff+pa8W+CfRZlo+ujpy 4/mnyKzk3UPlxeySddTUh9OnvIdmIJGSJPG4jX+FFcqozF3tgSqURGrtWssC8tsEJ5L5 7HsYkIPLgCj+SQNAG650BV6/pJiejJp3VOZdo/VV3xvemMJ4NY1wkFy36yGmkEqhSPKS f9ig== X-Gm-Message-State: ABy/qLb250IXEYMYE2d214KEN08h0w7cE4DXHuBthleE4DjrXjfs6jXy lnLKNGRxsx8+Sj3tIHueYyIz5g== X-Google-Smtp-Source: APBJJlGDVDh+1yI0CNPJWJIWNk8lVob7KVUMQooGlcjvO+DgUuNP7qUSrm8sB8FynWkProStTO49Ag== X-Received: by 2002:a05:620a:98f:b0:767:82e8:eb88 with SMTP id x15-20020a05620a098f00b0076782e8eb88mr6374308qkx.7.1690158370570; Sun, 23 Jul 2023 17:26:10 -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 a14-20020a05620a16ce00b00767d6ec578csm2675643qkn.20.2023.07.23.17.26.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jul 2023 17:26:09 -0700 (PDT) Date: Sun, 23 Jul 2023 20:26:08 -0400 From: Ben Boeckel To: Nathan Sidwell Cc: Jason Merrill , 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: <20230623024559.GA255658@farprobe> <541367ff-25da-9745-d768-c60f235cd5bc@acm.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <25ec1e77-fffd-1f39-c797-4a9ba982b22d@acm.org> User-Agent: Mutt/2.2.9 (2022-11-12) X-Spam-Status: No, score=-3.1 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 Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote: > It occurs to me that the model I am envisioning is similar to CMake's object > libraries. Object libraries are a convenient name for a bunch of object files. > IIUC they're linked by naming the individual object files (or I think the could > be implemented as a static lib linked with --whole-archive path/to/libfoo.a > -no-whole-archive. But for this conversation consider them a bunch of separate > object files with a convenient group name. Yes, `--whole-archive` would work great if it had any kind of portability across CMake's platform set. > Consider also that object libraries could themselves contain object libraries (I > don't know of they can, but it seems like a useful concept). Then one could > create an object library from a collection of object files and object libraries > (recursively). CMake would handle the transitive gtaph. I think this detail is relevant, but you can use `$` as an `INTERFACE` sources and it would act like that, but it is an explicit thing. Instead, `OBJECT` libraries *only* provide their objects to targets that *directly* link them. If not, given this: A (OBJECT library) B (library of some kind; links PUBLIC to A) C (links to B) If `A` has things like linker flags (or, more likely, libraries) as part of its usage requirements, C will get them on is link line. However, if OBJECT files are transitive in the same way, the linker (on most platforms at least) chokes because it now has duplicates of all of A's symbols: those from the B library and those from A's objects on the link line. > Now, allow an object library to itself have some kind of tangible, on-disk > representation. *BUT* not like a static library -- it doesn't include the > object files. > > > Now that immediately maps onto modules. > > CMI: Object library > Direct imports: Direct object libraries of an object library > > This is why I don't understand the need explicitly indicate the indirect imports > of a CMI. CMake knows them, because it knows the graph. 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. --Ben