> gcc (and other compilers like clang) support emitting dependency information in the syntax of a Makefile.
But didn't quite make it to the second paragraph:
> (Ninja only supports the limited subset of the Makefile syntax emitted by compilers.)
Obviously Ninja can't parse and execute full Makefile syntax because then it would just be Make. But the actual information in depfiles doesn't require the full Makefile syntax; only a subset of it. And compilers output that subset, so Ninja can read it.
The issue is it's a de facto subset - a "depfile syntax" that exists by convention but the GNU authors have broken this format. As I said, unless there's a good reason to break it, that's just shitty behaviour.
I already knew that Ninja only supports a limited subset and that the issue is the compiler now going beyond that limited subset.
My point is that I wouldn't jump to conclusions as to why they did that. I would dig further to see what the reasons were (which is not a simple google search) and what Ninja developers could do about that.
Another important point is that they didn't break Ninja compatibility in general, but only in the specific case of C++ modules; and they also didn't break compatibility with non-GNU implementations of Make.
> But the actual information in depfiles doesn't require the full Makefile syntax; only a subset of it.
That seems to be the problem, the information introduced for the module support[1] apparently cannot be handled with just the dependency lists alone and the changes suggested in the ticket would still leave the additional CXX_IMPORTS += M1.c++m syntax. One of the commenters on the ticket also wrote a specification for a json based dependency format[2].
