From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 7B39638346B4 for ; Thu, 21 Apr 2022 18:18:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B39638346B4 Received: by mail-wr1-x435.google.com with SMTP id s25so2938959wrb.8 for ; Thu, 21 Apr 2022 11:18:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NjCwLobiIbAzduo284D5/GFWod0E4xVRMqjFimt/WBc=; b=XybqtcyNmJKx9kAazyLtS2sdsIP09ImavBRuAWbyJnGYioYfS22wdaumy9Ih1hhS+e 0OZiFjLI3XeE3Nxuo7V/pV9OaL0d73EJLu5q2v6R5IxwLxgHX8OHJnXhVcqY/poq7ZkG 8yoL8lG2V6uhic2xuF7OHSrao6uFCNXeFm6Qy76gXrtb/r/ybmaO+hp7ic3jrclIPCmf xQoFV8N07nzWM3ZQKslTGeSHQH15gIJoFkyDf2qL99ONjGz0bH/uHG72yOcDZCyKY43R v5fMsaitaIC/mqG4V4CVix9hQAkXQbLhTHKWrcVbgZzdopvnyZipafW+V+qWvjdkgtJI qagA== X-Gm-Message-State: AOAM532UXIgVVg7sGG1OsBD53p8U3PtB0foj8Fx1EBPd/gc2uFUoZR4Z BesD0jWEMfuS1VaF0y4GYLE= X-Google-Smtp-Source: ABdhPJxTVyO9u1kLZu7BufA6v5/ygxKoxFVVBnfhXsYZDUP7KYnzaKQAZA43FV9HbN4KbNTBXEcYcA== X-Received: by 2002:a05:6000:1686:b0:20a:96e0:9bbe with SMTP id y6-20020a056000168600b0020a96e09bbemr685689wrd.635.1650565110185; Thu, 21 Apr 2022 11:18:30 -0700 (PDT) Received: from [192.168.1.214] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id l9-20020a1c7909000000b0038eb8171fa5sm2591614wme.1.2022.04.21.11.18.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Apr 2022 11:18:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [modules] Preprocessing requires compiled header unit modules From: Iain Sandoe In-Reply-To: Date: Thu, 21 Apr 2022 19:18:29 +0100 Cc: Boris Kolpackov , gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <5DD78076-C7C2-4941-9E04-A97DAC305C63@googlemail.com> References: To: Ben Boeckel X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2022 18:18:33 -0000 > On 21 Apr 2022, at 19:08, Ben Boeckel wrote: >=20 > On Thu, Apr 21, 2022 at 18:59:56 +0100, Iain Sandoe wrote: >> Hi Ben, >>=20 >>> On 21 Apr 2022, at 13:05, Ben Boeckel via Gcc = wrote: >>>=20 >>> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote: >>>> I don't think it is. A header unit (unlike a named module) may = export >>>> macros which could affect further dependencies. Consider: >>>>=20 >>>> import "header-unit.hpp"; // May or may not export macro FOO. >>=20 >> 1. If you know how this was built, then you could do an -E = -fdirectives-only build (both >> GCC and clang support this now) to obtain the macros. >=20 > My understanding is that how it gets used determines how it should be > made for Clang (because the consumer's `-D`, `-W`, etc. flags matter). = I > do not yet know how I am to support this in CMake. I think that is what I mean by =E2=80=9Cif you know how it is built=E2=80=9D= - it means you can replicate those conditions, but produce the fdirectives-only output. Perhaps I=E2=80=99m = missing a subtelty =E2=80=A6 >> 2. I suppose we could invent a tool (or FE mode) to dump the macros = exported by a HU *** >=20 > Fun considerations: >=20 > - are `-D` flags exported? `-U`? > - how about this if `value` is the same as or different from the > at-start expansion: >=20 > ```c++ > #undef SOME_MACRO > #define SOME_MACRO value > ``` >=20 > - how about `#undef FOO`? AFAIU, that is defined by the standard - only the defined state of a = macro is exported. So if the file contains #define FOO 1 =E2=80=A6. =E2=80=A6. #undef FOO =E2=80=94 there will be no mention of FOO in the exported macros (at = least, that is what my impl. does ;) ). =E2=80=94 and the output would contain 'SOME_MACRO value=E2=80=99 for = your other case. This is quite different from the behaviour of PCH where the macro = history is preserved. >>>> #ifdef FOO >>>> import "header-unit2.hpp" >>>> #endif >>>=20 >>> I agree that the header needs to be *found*, but scanning cannot = require >>> a pre-existing BMI for that header. A new mode likely needs to be = laid >>> down to get the information necessary (instead of just piggy-backing = on >>> `-E` behavior to get what I want). >>=20 >> perhaps that means (2)? >=20 > Can't it just read the header as if it wasn't imported? AFAIU, that's > what GCC did in Jan 2019. I understand that CPP state is probably not > easy, but something to consider. The BMIs (at least the two I=E2=80=99ve got some familiarity with) are = quite complex - there would have to be some mode that specifically extracted the macros only. >> *** it=E2=80=99s kinda frustrating that this is hard infomation to = get as a developer, so >> perhaps we can anticipate users wanting such output. >=20 > I think cacheing and distributed build tools are the most likely > consumers of such information. On an =E2=80=9Cindustrial scale=E2=80=9D, sure - but the ability for a = user to check that what they think is present _is_ present, is valuable - at least in debug. Iain