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, <g...@gcc.gnu.org> wrote: > >> On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran > >> <fort...@gcc.gnu.org> 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
