[Bug c++/105467] New: Dependency file produced by C++ modules causes Ninja errors

[Bug c++/105467] New: Dependency file produced by C++ modules causes Ninja errors

[jpakkane at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

            Bug ID: 105467
           Summary: Dependency file produced by C++ modules causes Ninja
                    errors
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jpakkane at gmail dot com
  Target Milestone: ---

Currently if you try to build C++ modules using Ninja and a dependency file,
things fail with this fairly cryptic error message (that comes from Ninja):

inputs may not also have inputs

The commend line is this:

g++ -Igcc/modtest.p -Igcc '-I../test cases/unit/85 cpp modules/gcc'
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Wnon-virtual-dtor -std=c++20 -O0 -g -fmodules-ts -MD -MQ
gcc/modtest.p/src0.cxx.o -MF gcc/modtest.p/src0.cxx.o.d -o
gcc/modtest.p/src0.cxx.o -c '../test cases/unit/85 cpp modules/gcc/src0.cxx

and the generated dependency file looks like this:

gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: \
 ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \
 /usr/include/stdc-predef.h
gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: M1.c++m
M0.c++m: gcm.cache/M0.gcm
.PHONY: M0.c++m
gcm.cache/M0.gcm:| gcc/modtest.p/src0.cxx.o
CXX_IMPORTS += M1.c++m

This sets things up so that the object file depends on the sources and the
generated module file depends on the object file only. Ninja does not like this
and errors out because it thinks that outputs (the .o file in this case) may
not be used as a dependency to other outputs.

A possible fix would be to set the dependencies of the module output to be the
same source files as are used for the object file. Something like this:

gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: \
 ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \
 /usr/include/stdc-predef.h
gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: M1.c++m
M0.c++m: gcm.cache/M0.gcm
.PHONY: M0.c++m
gcm.cache/M0.gcm: \
 ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \
 /usr/include/stdc-predef.h
CXX_IMPORTS += M1.c++m

The corresponding Ninja bug is here:
https://github.com/ninja-build/ninja/issues/1962

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[bugzilla.gcc at me dot benboeckel.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla.gcc at me dot benboeckel.
                   |                            |net

--- Comment #1 from Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> ---
-fdeps-format=p1689r5 will suppress this extra information. A new
`-Mno-modules` flag may be more useful (and certainly discoverable).

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[jpakkane at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #2 from jpakkane at gmail dot com ---
It would be preferable to have the default work out of the box than having
every end user having to add compiler flags to make things work.

Ninja is the most popular underlying build system for modules, having it work
by default would make things easier for many people.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[saifi.khan at nishan dot io]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

Saifi Khan <saifi.khan at nishan dot io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |saifi.khan at nishan dot io

--- Comment #3 from Saifi Khan <saifi.khan at nishan dot io> ---
(In reply to jpakkane from comment #2)
> It would be preferable to have the default work out of the box than having
> every end user having to add compiler flags to make things work.
> 
> Ninja is the most popular underlying build system for modules, having it
> work by default would make things easier for many people.

as an end user, i'd prefer to explicitly add compiler flag instead of getting
pinja, hazel, teson or some such by default !

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[jpakkane at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #4 from jpakkane at gmail dot com ---
As a build system developer I'd like that the most common usage (i.e. using
Ninja) would be the default and work without extra compiler flags.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to jpakkane from comment #4)
> As a build system developer I'd like that the most common usage (i.e. using
> Ninja) would be the default and work without extra compiler flags.

Ninja is not the most common usage. GNU make still is the most common usage for
build systems out there. Especially since gcc should work best with the gnu
software first.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[jpakkane at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #6 from jpakkane at gmail dot com ---
According to C++ foundation's developer survey [1] the most popular build
system for C++ projects is CMake by quite a massive margin. Based on personal
experience almost everybody uses CMake's Ninja backend rather than the Make
backend on unixy platforms simply because it is so much faster 

CMake does not support modules in the Make backend [2]. Some people even claim
that properly supporting Make to build C++ modules is not possible if you want
to make it actually production quality and reliable.

Modules are very much a forward looking thing. People who still use plain Make
are most likely doing so on legacy projects that can not adopt modules in the
near future in any case.

Thus it would seem that the most probable ways C++ modules are going to be used
are a) VS projects b) whatever Xcode ends up implementing c) Ninja files.


[1] https://isocpp.org/files/papers/CppDevSurvey-2023-summary.pdf

[2] https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Anyways gcc should work best with gnu software and cmake is not at all gnu
software and it competes with autoconf and automake which are gnu tools. Cmake
is less portable than the autotools.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[bugzilla.gcc at me dot benboeckel.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #8 from Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> ---
> Some people even claim that properly supporting Make to build C++ modules is not possible if you want to make it actually production quality and reliable.

It is possible, but, AFAIK, requires at least one level of recursive make (to
deal with the dynamic files). Note that CMake also generates POSIX Make and
only uses GNU-specific things to disable things like builtin rules.

> GNU make still is the most common usage for build systems out there.

Overall? Sure; I don't have data to say otherwise. For C++ modules? Highly
unlikely unless autoconf/automake started relying on the non-GNU `fdep` [1]
project.

My concerns include:

- tools have learned to read the *restricted* syntax historically used by `-MF`
output and would need to grow new logic to deal with the `+=` usage
- the variable name is hard-coded

I think the following flags make sense to add:

- `-Mmodules` to explicitly request this extra information
- `-Mno-modules` to suppress it
- `-MMV varname` to select the variable name used (though maybe
`-Mc++module-variable=<varname>` is better)

> Anyways gcc should work best with gnu software and cmake is not at all gnu software and it competes with autoconf and automake which are gnu tools.

I eagerly await C++ module support in autoconf and automake in that case.
AFAIK, the support is in GNU make only and significant infrastructural support
is missing from autoconf/autotools to reliably support them (namely things like
installation assistance, enforcing visibility of modules between libraries, and
not using stale module files).

> Cmake is less portable than the autotools.

There is a significant set of platforms that CMake supports that autotools does
not, but yes…CMake certainly supports fewer total number platforms than
autotools (though when weighted by relevance…). I'd say there's not a total
ordering here.

[1] https://gitlab.mpcdf.mpg.de/elpa/elpa/-/tree/master/fdep

FD: CMake developer and primary implementer of C++ module support in it.

[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors

[bugzilla.gcc at me dot benboeckel.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467

--- Comment #9 from Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> ---
> unless autoconf/automake started relying on the non-GNU `fdep` [1] project.

Gah, editing gone awry. This was about Fortran module support in
autoconf/autotools, not C++ module support (they have similar build graph
strategies required).