It is possible to get the working copy of Python 2.7 in a state such that any attempt to do "make" ends with the error shown in the title.  The working copy is perfectly valid; it is a matter of getting the wrong timestamps on the files.

(Despite the error message, this is not directly related to issue10013 or "make -j".)

I didn't try Python 3.x, but the same issue might apply.

How to reproduce:

- get your checkout, let's say in python/src/

- go to your build directory, say python/build/, and run "../src/configure; make".

- then, in the src dir, give Include/graminit.h a more recent timestamp than Python/graminit.c, for example by saying "touch Include/graminit.h" (this is the crux: a common mercurial checkout will order them the other way, just because of alphabetical ordering).

- remove your python/build/ directory completely, create it anew, and run again "../src/configure; make".

The cause of the message is that the Makefile rule for $(GRAMMAR_C) runs, because the GRAMMAR_H file is more recent; but the GRAMMAR_H rule does nothing, because the latter is already up-to-date.  So the only thing that runs is "touch $(GRAMMAR_C)".  But this creates an empty file build/Python/graminit.c!

It looks like this was caused by the changes for Issue14321 to not run pgen for cross builds.

BTW, this can be worked around (for non cross-builds at least) by running "make touch" on the source directory, e.g.:

    make -C python/src -f python/build/Makefile touch

But it should be fixed.  Doko?

The same $(GRAMMAR_H) dependency and touch command still exists today, so I suspect this is still valid (though I didn’t try to reproduce it). I think we need to figure out if you can write a proper makefile rule that handles a single command that updates two targets at once.

FWIW I don’t think “make touch” will currently help on Python 2, because it only affects two files that are generated by pgen (see also my comment in Issue 19142).

We no longer have GRAMMAR_H or _PyParser_Grammar in the code.