From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by sourceware.org (Postfix) with ESMTPS id A34A83858CD1; Thu, 20 Jul 2023 21:00:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A34A83858CD1 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-qk1-x72e.google.com with SMTP id af79cd13be357-7653bd3ff2fso134261785a.3; Thu, 20 Jul 2023 14:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689886834; x=1690491634; 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=2D5uLJpGP5ovt/39q0mAMMNbCVhWBvNJjVrciZ5ZwZc=; b=FqlZXskfUawcMnLS+1sCKGRA0wgyEiFEVS+TEQ4JjMaq9irtWpmlzBAbY89Kx3c3lC kKJSzdOVBZQ1CMMv3reNSm9UsUMJUZQHNeb9kSHXQqYHe7jO2OrJaukn5ycgI2BxlVtj 7j/yA+b0Q57RDbAw7rkK6yJNyN5cv2YfuTEds+iwz24fcFhVC1ekH/l9DE5UfNwkiFDU ufAmXZBrT4XiHShppPazCqjMpWC45AOjevE9VKvVgK9fKOtB7QudPNZRfjOD3Tn70E5J TwlIC34sLvzgIkLaHElDD9ZoFLM6FROi0HUdXRXVPyqR0X3QJ2RUM9gDp6gIWKrkeWw7 yeAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689886834; x=1690491634; 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=2D5uLJpGP5ovt/39q0mAMMNbCVhWBvNJjVrciZ5ZwZc=; b=EnlINjNd0+Yyw91Qh1ZvRtFv8HPtNJYBYARAnXXnGR26ql4crv2a37gvmPzRmYlURY 2hrMC3XqVV7KIr6jWfrHy/5tcsJF/N1/1jgkHYp75x12xCDOmdIbVb9wuFVhYojXdNaf RDcwkZtNkUGmkEwrA10dRTeVbt/5TbZxtqbEWwC2k35Ht4+AhQn+nGurs/NPy5KsY/P6 q1UWaj3FaI00p5eqSuunG2wkdjP82ZaYG0URT+LbfvOZWROkaVdULV1hKijVUM9+XQCK GwbHgdIExvkpm0X/XkxI4PHG4TYkZpnMnaSrtDaWGipTrXXn4wi5lqXfug0XXpQPD0Ik IElQ== X-Gm-Message-State: ABy/qLb3w/5I5Zxp+UaXMYSaZSIaH1lXoKHkJ+IqOjCuOwjcQXgdxNFE iNFRdGePuU+6nRptRgtWM+w= X-Google-Smtp-Source: APBJJlHQcHm8OV1gVPNSjvd5RXDJPCRj6eDZuiO9kXh2ey2zkb/JAVEifDBAvh7DaliRXZ9MNbWx3g== X-Received: by 2002:a05:620a:462c:b0:767:923:48e7 with SMTP id br44-20020a05620a462c00b00767092348e7mr30871723qkb.5.1689886833848; Thu, 20 Jul 2023 14:00:33 -0700 (PDT) Received: from ?IPV6:2601:19c:5282:9160::1? ([2601:19c:5282:9160::1]) by smtp.googlemail.com with ESMTPSA id t12-20020a05620a004c00b00767cf270628sm611018qkt.131.2023.07.20.14.00.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Jul 2023 14:00:33 -0700 (PDT) Sender: Nathan Sidwell Message-ID: <61774849-b8e5-fb9e-2e30-d6b6cee08859@acm.org> Date: Thu, 20 Jul 2023 17:00:32 -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-1-ben.boeckel@kitware.com> <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> From: Nathan Sidwell In-Reply-To: <20230720004723.GA1159121@farprobe> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3031.7 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/19/23 20:47, Ben Boeckel wrote: > On Wed, Jul 19, 2023 at 17:11:08 -0400, Nathan Sidwell wrote: >> GCC is neither of these descriptions. a CMI does not contain the transitive >> closure of its imports. It contains an import table. That table lists the >> transitive closure of its imports (it needs that closure to do remapping), and >> that table contains the CMI pathnames of the direct imports. Those pathnames >> are absolute, if the mapper provded an absolute pathm or relative to the CMI repo. >> >> The rationale here is that if you're building a CMI, Foo, which imports a bunch >> of modules, those imported CMIs will have the same (relative) location in this >> compilation and in compilations importing Foo (why would you move them?) Note >> this is NOT inhibiting relocatable builds, because of the CMI repo. > > 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. > - 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. > 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. > >> On 7/18/23 20:01, Ben Boeckel wrote: >>> Maybe I'm missing how this *actually* works in GCC as I've really only >>> interacted with it through the command line, but I've not needed to >>> mention `a.cmi` when compiling `use.cppm`. Is `a.cmi` referenced and >>> read through some embedded information in `b.cmi` or does `b.cmi` >>> include enough information to not need to read it at all? If the former, >>> distributed builds are going to have a problem knowing what files to >>> send just from the command line (I'll call this "implicit thin"). If the >>> latter, that is the "fat" CMI that I'm thinking of. >> >> please don't use perjorative terms like 'fat' and 'thin'. > > Sorry, I was internally analogizing to "thinLTO". > > --Ben -- Nathan Sidwell