From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by sourceware.org (Postfix) with ESMTPS id 617BF385783F for ; Fri, 3 Feb 2023 14:52:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 617BF385783F 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-x832.google.com with SMTP id g18so3349652qtb.6 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=r45Z5GO00giZd/s299h5QjsrTFBeVQEjWbjkZLUx8m3uQ2khH4xNCQJaCFOx87CHa9 V8bUjsLdLhy6Kl/4jzouqzXtp2ema2r/kvFiELVwxzEqGWN5MDAeIjkohRjAU3hZCqfL yHsMhG+qeadRqcfBFvuBZY2yR2jmFmyi7/VO/bmj6HkTDTutYn/kSoHGHjcmZPhEcSic BOV6NM0V4+rq64g2lvT3Q6Z9y0sbRmukccSM8MFtIiTaTi8NlSey3pCRpAaCbtLG8NSS gWEKlcqz+9FSa0FyZ/WnvW+m74PK7il9oAR2enVB19JuLnKjP1sE6KBBGUa7r1Rh0QZ6 ZuPw== X-Gm-Message-State: AO0yUKXjwFGILSWvKTNci5JzFUudm8knHnPAvYMz6hHf2Iun//Z+R9fW enqgLh6r+7cnGE5row3KdeBhhQ== 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=-5.8 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