From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by sourceware.org (Postfix) with ESMTPS id 70458384F00C for ; Fri, 3 Feb 2023 14:52:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 70458384F00C 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-qt1-x831.google.com with SMTP id w3so5659387qts.7 for ; Fri, 03 Feb 2023 06:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kitware.com; s=google; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Xldos1kTa7NEp5s/npzF9N6VS1oWuH3l4AWdLVNsKSE=; b=HKcJfrguSUGtKcJ6Ti+M+IVKfs6ccnCnOF9gAxcU1MufTbE6IRl8z+5t9iQaBiJZsn fJ13ItGR+ALM2eOCCXl1ENTLVzkhCySyTQEsSkg9eQ+kzmoTvk41JqcZACRjBT7F4/Y9 fzk33rbHLWT/71eruS6XPB0O1hGo9FkH6rOlA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-transfer-encoding :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=Xldos1kTa7NEp5s/npzF9N6VS1oWuH3l4AWdLVNsKSE=; b=URoStKSU2dc5Pde04kJ8VbFeZhrhSqKMAh34gJ3Uh3rkrUjGkBIPNkei9aeqhHndx3 ZBcKdZ10zV772zsGY8JvqPm8EJFDNUz4F0ndeTGFhlnyXEXgASdwd5pjvPveTCSXA2jG LNs8kbCTOctKktPqZHxHnCv6HYpNJN4e+X31Q+5Qi0W7f7YRrcb5MVH6FmjFcpcu3pAc 5N8lcunKJoJXS1L3DSRde0CM05W+evP5ElpRSD9YYQKRcrmqimONMkMUR6B0wX9mYi1y Hz1No+suIu3mP9R87SMLmZjuCePc959l1FcLMf7dgUasAAOt8qDFlMIgb2gg7hi5lXKJ k62g== X-Gm-Message-State: AO0yUKWD8f4wA3dj5sLfiJG51H4pOb5TE5t224ni1f6t2YtpFkbLGshd euN/j5yY/TYIpsfMwa0gl8FknA== X-Google-Smtp-Source: AK7set/vHiYlxIDPvOqro9TpnnV8G8/2GjauJZnWOMA/Y31caPrHyK/C+/xswnIs65B2ZPSbJYdM/A== X-Received: by 2002:ac8:5c06:0:b0:3b8:682d:cebf with SMTP id i6-20020ac85c06000000b003b8682dcebfmr19833016qti.66.1675435977765; Fri, 03 Feb 2023 06:52:57 -0800 (PST) Received: from localhost (cpe-142-105-146-128.nycap.res.rr.com. [142.105.146.128]) by smtp.gmail.com with ESMTPSA id c29-20020ac8009d000000b003b323387c1asm1679451qtg.18.2023.02.03.06.52.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 06:52:57 -0800 (PST) Date: Fri, 3 Feb 2023 09:52:56 -0500 From: Ben Boeckel To: Jonathan Wakely Cc: Andrew Pinski , gcc-patches , Jason Merrill , Nathan Sidwell , "fortran@gcc.gnu.org List" , "gcc@gcc.gnu.org" , brad.king@kitware.com Subject: Re: [PATCH v5 0/5] P1689R5 support Message-ID: References: <20230125210636.2960049-1-ben.boeckel@kitware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) X-Spam-Status: No, score=-4.6 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 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 Fri, Feb 03, 2023 at 09:10:21 +0000, Jonathan Wakely wrote: > On Fri, 3 Feb 2023 at 08:58, Jonathan Wakely wrote: > > On Fri, 3 Feb 2023, 04:09 Andrew Pinski via Gcc, wrote: > >> On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran > >> wrote: > >> > This patch series adds initial support for ISO C++'s [P1689R5][], a > >> > format for describing C++ module requirements and provisions based on > >> > the source code. This is required because compiling C++ with modules is > >> > not embarrassingly parallel and need to be ordered to ensure that > >> > `import some_module;` can be satisfied in time by making sure that any > >> > TU with `export import some_module;` is compiled first. > >> > >> I like how folks are complaining that GCC outputs POSIX makefile > >> syntax from GCC's dependency files which are supposed to be in POSIX > >> Makefile syntax. > >> It seems like rather the build tools are people like to use are not > >> understanding POSIX makefile syntax any more rather. > >> Also I am not a fan of json, it is too verbose for no use. Maybe it is > >> time to go back to standardizing a new POSIX makefile syntax rather > >> than changing C++ here. I'm not complaining that dependency files are in POSIX (or even POSIX-to-be) syntax. The information requires a bit more structure than some variable assignments and I don't expect anything trying to read them to start trying to understand `VAR_$(DEREF)=` and the behaviors of `:=` versus `=` assignment to get this reliably. > > That would take a decade or more. It's too late for POSIX 202x and > > the pace that POSIX agrees on makefile features is incredibly slow. > > Also, name+=value is *not* POSIX make syntax today, that's an > extension. That's why the tools don't always support it. > So I don't think it's true that GCC's dependency files are in POSIX syntax. > > POSIX 202x does add support for it, but it will take some time for it > to be supported everywhere. Additionally, while the *syntax* might be supported, encoding all of P1689 in it would require additional work (e.g., key/value variable assignments or something). Batch scanning would also be…interesting. Also note that the imported modules' location cannot be known before scanning in general, so all you get are "logical names" that you need a collator to link up with other scan results anyways. Tools such as `make` and `ninja` cannot know, in general, how to do this linking between arbitrary targets (e.g., there may be a debug and release build of the same module in the graph and knowing which to use requires higher-level info about the entire build graph; modules may also be considered "private" and not accessible everywhere and therefore should also not be hooked up across different target boundaries). While the `CXX_MODULES +=` approach can work for simple cases (a pseudo-implicit build), it is quite insufficient for the general case. --Ben