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 0E4173858C78 for ; Thu, 20 Jul 2023 00:47:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E4173858C78 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-xf2c.google.com with SMTP id 6a1803df08f44-63719ad32e7so1850756d6.1 for ; Wed, 19 Jul 2023 17:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kitware.com; s=google; t=1689814045; x=1690418845; 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=FcQnk83aWzP6f6Fs+ix8IH2SvBM8eJvQ37HUCihUjic=; b=o0Qrep2+bvbdNvsdD0NFyDvh5kofWLkupT8oEsR/Z+SsAcchmy9lfC1SOBSmZo3RI2 Tvkzf40PFJIEEGD+Bd7D3js6XIpQMmByGiNZtcUzIU7FO8qqetcZ/2SbwhoWg6tTXDES 4BxI7uAjSi7daPNAWMUYubtw9kXP8DN6IgSWg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689814045; x=1690418845; 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=FcQnk83aWzP6f6Fs+ix8IH2SvBM8eJvQ37HUCihUjic=; b=hUUwHUAQeOcJs+Po5Lhcj11oY+F3Wc6K6YGv/X5MQ0ivRC4/i3bLENlrY4ggbj8Rc3 dAbjjPJGoT8ZVvnp4IsINPz9XTW9fSUm6k8E58r/YNRGXimHt9wnhcZUgAmHQ1ksbot4 ua/wxmr68/qYXE/Hh5Xv8widDaNkGJatrZNQtdTodGgwPj5daYSNBigtIHzx5PCN0lGF Owe4p84WSBF3RWE6gfzUemHExdWGpyI1Cb6l+QUXVULX9MIDSGDEffImFfaWvgcV7OE5 MNgtJjwieHuV+owPXV+oZf3lmf0bGIlaUnl0ZzYgTT/6+VZuAu6GoOCMwuYA++sruX+6 /qAw== X-Gm-Message-State: ABy/qLZZTRCmE3dTLLVH3g/qz7rJMHap68l6x5jyqYXna6ts9PZxoJOO J4WlqAn1xh1ZD6HRLwYtsIFWMQ== X-Google-Smtp-Source: APBJJlEgEAIUle0BtIpU+qe9kQwDzXGcqgx0Is0Ti+WRmuzBmu8WiNtuZJsunz1p6KziJWstgn3N5g== X-Received: by 2002:a0c:e381:0:b0:634:d868:f0dd with SMTP id a1-20020a0ce381000000b00634d868f0ddmr741831qvl.50.1689814045479; Wed, 19 Jul 2023 17:47:25 -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 q17-20020a0ce211000000b0063c5fdf65b4sm1806880qvl.130.2023.07.19.17.47.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 17:47:24 -0700 (PDT) Date: Wed, 19 Jul 2023 20:47:23 -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: <20230720004723.GA1159121@farprobe> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <80a2e5b6-0580-c3f5-cb75-c8795ebabceb@acm.org> User-Agent: Mutt/2.2.9 (2022-11-12) X-Spam-Status: No, score=-4.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 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); - 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. 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)? > 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