From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 897A53858D37 for ; Fri, 28 Jul 2023 01:13:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 897A53858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690506832; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uuAr2w3B1TW5eoYcLA7KK5yRGa8333tucQfQJ5xpM7E=; b=hQSPlB6kGxqlhZPGEkfIPqJnAmA8i8I/vi3lGGHg8LpgL9dYcbuOOf4Z2rPrFZhw/hPjZc mijng0R3C4dLP1JUcTlnMEEIRMorVqbAIldqR6zbDeLxfINNsUO3IrtnDgbwamy6NtawQW ltZU3hrBgMBkelo5cw67AJReTO63+Jw= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-654-ZBgeqN82OGmWTkB8qQ1Sng-1; Thu, 27 Jul 2023 21:13:51 -0400 X-MC-Unique: ZBgeqN82OGmWTkB8qQ1Sng-1 Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-1bbb34b0abaso15512845ad.1 for ; Thu, 27 Jul 2023 18:13:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690506830; x=1691111630; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uuAr2w3B1TW5eoYcLA7KK5yRGa8333tucQfQJ5xpM7E=; b=W6saEQEc5XefJX5Pvl+fiydRwCHPRk5qwIdYLn8mz/I2AeG3x0uLAbrb1JQUkxmBfK V0z8xhAU9zZ5vh63Y/GV+Bn/lGQwJLdJgS4uTiSNBoSnUQmkznfwzelQVMeAjxxcYglK EJDmqfoCOIHh9UDKadpEZ2YYwqC2k/VVai2PffBX8TlrMBoZ0XhuMqsznOgBy9KibT6u ZfyBQIo4mCIv+UTHQVqGDA5f/+yl8UDLC2p+4eAriB39EvpsMyJkEy6haq8pCaajFG8Q isFWuDlOb4Jf24Ya04Hm4wXS/c52ZOpJo58nDwreWtJjN3nNquki6gfjN1ybH+zG+Sq3 90xQ== X-Gm-Message-State: ABy/qLb29pZw3O3qA25yKCGIWGJvfI/DjWeuM+6O6PwkD8XEQH+1RUYA 7IccIrJAbCjvlcb0hhe+AfUtonS3qw7GQkKi2/L2pERRS22uZutLjzMJP1AOnKIlYep0BIX0Vda rXZIG7Z9TNFegLERTTw== X-Received: by 2002:a17:903:11d0:b0:1b8:6a09:9cf9 with SMTP id q16-20020a17090311d000b001b86a099cf9mr317424plh.26.1690506830408; Thu, 27 Jul 2023 18:13:50 -0700 (PDT) X-Google-Smtp-Source: APBJJlGpJQ7KbgZbhzZ4Zzl/V4RMNhefbktSg7teh6Ns8hJF8VOWe5emyfzyUculEhTzpD0IYaTGwQ== X-Received: by 2002:a17:903:11d0:b0:1b8:6a09:9cf9 with SMTP id q16-20020a17090311d000b001b86a099cf9mr317405plh.26.1690506829983; Thu, 27 Jul 2023 18:13:49 -0700 (PDT) Received: from [192.168.0.67] (75-172-17-121.tukw.qwest.net. [75.172.17.121]) by smtp.gmail.com with ESMTPSA id b11-20020a170903228b00b001b8943b37a5sm2270188plh.24.2023.07.27.18.13.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jul 2023 18:13:49 -0700 (PDT) Message-ID: <8299af0b-f648-3a4b-83f6-86b9191d20c9@redhat.com> Date: Thu, 27 Jul 2023 18:13:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies To: Ben Boeckel , Nathan Sidwell Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, gcc@gcc.gnu.org, brad.king@kitware.com 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> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 7/23/23 20:26, Ben Boeckel wrote: > 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. 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 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. Jason