From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by sourceware.org (Postfix) with ESMTPS id 433B2385DC0C; Fri, 21 Jul 2023 20:23:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 433B2385DC0C Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-635e0e6b829so16852236d6.0; Fri, 21 Jul 2023 13:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689970989; x=1690575789; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=QFnfu3Q6YtoSfCGMMku8XXheHR/5qtMcWdbW7C0xs+0=; b=YyraaSNxatjnSivzQ+Gtz5PmPDHdIczowx8gRF27lk6qxhl33MprCb/bbr65INip99 j8Nx4ZiMTWNoOMJBSUBBQz4ksNct+xlZm5OkMfqnBLPnsYM5AAdLb+ihxJBBrAPtQu9r Li1CgLaqK5Zoccq5GBBlQV2vXbhCPD4oAlNWZy+2ImBISMOhaWxphdULzj1JAU31Pwjk jJquzx7rRMzvJi4vV9resMtejNSJpF6i82GaPsvL9tzU+sM38VzXYmZ0U17Fc8e3wHKR rCFtqzSrlxg05Wi3thVpphbJmTqARffzksbkb5/Gz+N4Jv63CSmdNXvEo9kL+fP36QEH Zs/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689970989; x=1690575789; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QFnfu3Q6YtoSfCGMMku8XXheHR/5qtMcWdbW7C0xs+0=; b=Dg500KLqDfZwZDjQrt5aXb4qvbQSMqYN/JXa1jn1tjrzmroNZuV9uVa4I54peUFGSS v78ynIvQ+Dt820yiInY3fibQrXzpywrXJ0HkcI2V2vhBxt+pg4LpuhFhQaqIP7CRWGGG FYjSX1CTOVcuOouRlV63VPetJ2u+/X+hYB/cflgQemiZLvsK1Xd0DGoiKduKR3goF86k 1laATy/8lk8T++Ek7TqYtj8Gb5rItOzB+W3lhC8uDOMQJ7JMLNNEroonUDYrIyvksaoe O1+tx5IWlBZeVuMrFUa7hWZ8/ME+OobWDnaODq6waQrH2VDxIE978x80GeMNtsAIl5IA s8FA== X-Gm-Message-State: ABy/qLZM0bVKlptWOgZRHKzeiWVcjvF9ApZF8FuvJfUPuswOhtSRMg5H RKVrMXUtDJPyTC7u+mdHLHE= X-Google-Smtp-Source: APBJJlEEFNHo0XuT21Q+hpGobb+EVA7YbNOc96vyZ5pavyaeFignXOYT3bmgix4/5twCgRCtvEmOeA== X-Received: by 2002:a05:6214:5155:b0:635:dd30:8181 with SMTP id kh21-20020a056214515500b00635dd308181mr1165880qvb.56.1689970988706; Fri, 21 Jul 2023 13:23:08 -0700 (PDT) Received: from ?IPV6:2601:19c:5282:9160::1? ([2601:19c:5282:9160::1]) by smtp.googlemail.com with ESMTPSA id d3-20020a05620a136300b0076639dfca8dsm1350746qkl.80.2023.07.21.13.23.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Jul 2023 13:23:08 -0700 (PDT) Sender: Nathan Sidwell Message-ID: <25ec1e77-fffd-1f39-c797-4a9ba982b22d@acm.org> Date: Fri, 21 Jul 2023 16:23:07 -0400 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 Content-Language: en-US To: Ben Boeckel Cc: Jason Merrill , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, gcc@gcc.gnu.org, brad.king@kitware.com References: <20230125210636.2960049-5-ben.boeckel@kitware.com> <734eef7c-f7c3-519c-e007-cb42f8dc8a82@redhat.com> <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> From: Nathan Sidwell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3031.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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/21/23 10:57, Ben Boeckel wrote: > On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote: >> On 7/19/23 20:47, Ben Boeckel wrote: >>> But it is inhibiting distributed builds because the distributing tool >>> would need to know: >>> >>> - what CMIs are actually imported (here, "read the module mapper file" >>> (in CMake's case, this is only the modules that are needed; a single >>> massive mapper file for an entire project would have extra entries) or >>> "act as a proxy for the socket/program specified" for other >>> approaches); >> >> This information is in the machine (& human) README section of the CMI. > > Ok. That leaves it up to distributing build tools to figure out at > least. > >>> - read the CMIs as it sends to the remote side to gather any other CMIs >>> that may be needed (recursively); >>> >>> Contrast this with the MSVC and Clang (17+) mechanism where the command >>> line contains everything that is needed and a single bolus can be sent. >> >> um, the build system needs to create that command line? Where does the build >> system get that information? IIUC it'll need to read some file(s) to do that. > > It's chained through the P1689 information in the collator as needed. No > extra files need to be read (at least with CMake's approach); certainly > not CMI files. 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. 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. 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. > >>> And relocatable is probably fine. How does it interact with reproducible >>> builds? Or are GCC CMIs not really something anyone should consider for >>> installation (even as a "here, maybe this can help consumers" >>> mechanism)? >> >> Module CMIs should be considered a cacheable artifact. They are neither object >> files nor source files. > > Sure, cachable sounds fine. What about the installation? > > --Ben -- Nathan Sidwell