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 8B0B7385735A for ; Wed, 23 Aug 2023 19:37:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B0B7385735A 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=1692819432; 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=DQk+FdJmh0DFythrXwPdBCuqY3wFgsWLhvHDV+VdvSk=; b=YY3JhR3vuiNImSURkMDtgr90EdM5OsnVXNJ51J0hTBiXg4KZ5KCD/fFUrjDBtzdreXyZon 6KWk0zLG2Gi1UZRZxbXg6m4SVoHXWOHPhmnxb221Zsj6UmTN36OgCttXMvm+CIgOiYfJyf VvdgooYJo+AH1G1OxtNNOsiq+TsPSos= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-434-iDhiuKiEN7y6RCV7Y1wVSw-1; Wed, 23 Aug 2023 15:37:10 -0400 X-MC-Unique: iDhiuKiEN7y6RCV7Y1wVSw-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-64b7c2a0d5dso69351096d6.3 for ; Wed, 23 Aug 2023 12:37:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692819430; x=1693424230; 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=DQk+FdJmh0DFythrXwPdBCuqY3wFgsWLhvHDV+VdvSk=; b=U4rB+SNkNfKHdUjaIRKfDC1+cWLI2NLkZZP2RyY5fzjA3aC8DVGe0OwB+Ex7wqfpKi fucllX7l2uae9RzuttVFkx5oupiz9mThqwOguk+5+qCGaQ6BItu71W3hytiDq+Z5mAC1 euupm5uHAUUg4nAHNBtZ8uG1+JisFWje0qiX8TV//po+m3DpERDb5c7f2aJeNrAGeMnF d1c8oOcq4vHQoOEuRbPoLra1mg5ppyWVOrmLHgiqVJ9oW4sl14dUEUepKuHN6WSB8sQL 3yaCjmQiOhKA9Zfy0toWuVM4b0M+yObxqW3ixbJnlCRlcIDMLpEPUaJwvnMkJXe7bfae UdPA== X-Gm-Message-State: AOJu0YxavzZt/I9WGds1feBMqpiZaTJEVqrl9vrQn75FUdxEp4gsqfmj dw1CGQV4AC0L9cH/reGkag1bQ8kCiW/Rt8LvoUrfey2lwfGXrXFuczxbYtN6wsad5T8RI1kV7S+ lXtYN0SLfkEGV X-Received: by 2002:a0c:e551:0:b0:64d:b496:7cb9 with SMTP id n17-20020a0ce551000000b0064db4967cb9mr10950951qvm.27.1692819430512; Wed, 23 Aug 2023 12:37:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGmagclEy65bGuKsTwTxd88KnZPhMtflHPWDHuYr4UZxsRhlFgM8bFXyqiC0yQAtz7IsjtiIw== X-Received: by 2002:a0c:e551:0:b0:64d:b496:7cb9 with SMTP id n17-20020a0ce551000000b0064db4967cb9mr10950935qvm.27.1692819430219; Wed, 23 Aug 2023 12:37:10 -0700 (PDT) Received: from [192.168.1.108] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id b26-20020a0cb3da000000b0064713c8fab7sm3824240qvf.59.2023.08.23.12.37.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Aug 2023 12:37:09 -0700 (PDT) Message-ID: <145995ff-9385-d095-1b8b-68a42b2d2341@redhat.com> Date: Wed, 23 Aug 2023 15:37:08 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v7 2/4] p1689r5: initial support To: Ben Boeckel , gcc-patches@gcc.gnu.org Cc: nathan@acm.org, fortran@gcc.gnu.org, gcc@gcc.gnu.org, brad.king@kitware.com References: <20230702163211.3396210-1-ben.boeckel@kitware.com> <20230702163211.3396210-3-ben.boeckel@kitware.com> From: Jason Merrill In-Reply-To: <20230702163211.3396210-3-ben.boeckel@kitware.com> 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=-15.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP 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 7/2/23 12:32, Ben Boeckel wrote: > This patch implements support for [P1689R5][] to communicate to a build > system the C++20 module dependencies to build systems so that they may > build `.gcm` files in the proper order. > > Support is communicated through the following three new flags: > > - `-fdeps-format=` specifies the format for the output. Currently named > `p1689r5`. > > - `-fdeps-file=` specifies the path to the file to write the format to. > > - `-fdeps-target=` specifies the `.o` that will be written for the TU > that is scanned. This is required so that the build system can > correlate the dependency output with the actual compilation that will > occur. > > CMake supports this format as of 17 Jun 2022 (to be part of 3.25.0) > using an experimental feature selection (to allow for future usage > evolution without committing to how it works today). While it remains > experimental, docs may be found in CMake's documentation for > experimental features. > > Future work may include using this format for Fortran module > dependencies as well, however this is still pending work. > > [P1689R5]: https://isocpp.org/files/papers/P1689R5.html > [cmake-experimental]: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst > > TODO: > > - header-unit information fields > > Header units (including the standard library headers) are 100% > unsupported right now because the `-E` mechanism wants to import their > BMIs. A new mode (i.e., something more workable than existing `-E` > behavior) that mocks up header units as if they were imported purely > from their path and content would be required. > > - non-utf8 paths > > The current standard says that paths that are not unambiguously > represented using UTF-8 are not supported (because these cases are rare > and the extra complication is not worth it at this time). Future > versions of the format might have ways of encoding non-UTF-8 paths. For > now, this patch just doesn't support non-UTF-8 paths (ignoring the > "unambiguously representable in UTF-8" case). > > - figure out why junk gets placed at the end of the file > > Sometimes it seems like the file gets a lot of `NUL` bytes appended to > it. It happens rarely and seems to be the result of some > `ftruncate`-style call which results in extra padding in the contents. > Noting it here as an observation at least. Thank you for your patience, just a few tweaks left and I think we can put this all in this week or next. > diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h > index aef703f8111..141cfd60eda 100644 > --- a/libcpp/include/cpplib.h > +++ b/libcpp/include/cpplib.h > @@ -302,6 +302,9 @@ typedef CPPCHAR_SIGNED_T cppchar_signed_t; > /* Style of header dependencies to generate. */ > enum cpp_deps_style { DEPS_NONE = 0, DEPS_USER, DEPS_SYSTEM }; > > +/* Structured format of module dependencies to generate. */ > +enum cpp_fdeps_format { DEPS_FMT_NONE = 0, DEPS_FMT_P1689R5 }; These should be FDEPS_FMT_* or just FDEPS_*. > @@ -395,10 +423,16 @@ make_write (const cpp_reader *pfile, FILE *fp, unsigned int colmax) > if (colmax && colmax < 34) > colmax = 34; > > + /* Write out C++ modules information if no other `-fdeps-format=` > + option is given. */ > + cpp_fdeps_format fdeps_format = CPP_OPTION (pfile, deps.fdeps_format); > + bool write_make_modules_deps = fdeps_format == DEPS_FMT_NONE && > + CPP_OPTION (pfile, deps.modules); We typically format an expression like this as: > + bool write_make_modules_deps = (fdeps_format == FDEPS_FMT_NONE > + && CPP_OPTION (pfile, deps.modules)); > @@ -473,6 +507,117 @@ deps_write (const cpp_reader *pfile, FILE *fp, unsigned int colmax) > make_write (pfile, fp, colmax); > } > > +static void > +p1689r5_write_filepath (const char *name, FILE *fp) This and the other p1689r5 functions need more comments, at least one at the top explaining their purpose. Jason