It's been awhile since I pulled from Mercurial and built, but I tried
today. I almost immediately ran into an error. The configure step
worked fine, but make, not so much:

% make
python  ./Tools/scripts/generate_opcode_h.py ./Lib/opcode.py ./Include/opcode.h
/opt/TWWfsw/bin/gmkdir -p Include
python ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "./Parser/asdl_c.py", line 1312, in <module>
    main(args[0], dump_module)
  File "./Parser/asdl_c.py", line 1251, in main
    if not asdl.check(mod):
  File "/home/skipm/3rdParty/python/cpython/Parser/asdl.py", line 183, in check
    v = Check()
  File "/home/skipm/3rdParty/python/cpython/Parser/asdl.py", line 140,
in __init__
    super().__init__()
TypeError: super() takes at least 1 argument (0 given)
make: *** [Include/Python-ast.h] Error 1

Trying to figure out what went wrong, I peeked in the Makefile and found:

ASDLGEN_FILES= $(srcdir)/Parser/asdl.py $(srcdir)/Parser/asdl_c.py
# XXX Note that a build now requires Python exist before the build starts
ASDLGEN= python $(srcdir)/Parser/asdl_c.py

This is bothersome on a couple levels. One, it assumes that "python"
means "Python 3" (which it doesn't mean here in the office). Two, it
doesnt' offer any suggestions about how to work around this "missing
bootstrap". After a couple minutes fussing around, I finally got
around the problem with a few judicious "touch" commands. It would be
nice if

* The above XXX comment was expanded to describe the necessary workaround

* Even better, some sort of "asdl-bootstrap" target (referenced in the
above comment) was added to the Makefile which sprinkled the necessary
pixie dust to artificially satisfy the AST_H and AST_C targets.

The bootstrap target shouldn't ever be executed automatically, but be
available to execute manually.

I think this would be sufficient:

# For people building for the first time without an existing Python 3
asdl-bootstrap:
	touch $(AST_H) $(AST_C)

Does "make touch" work for you as well?

Skip, PTAL at the devguide.

https://docs.python.org/devguide/setup.html#avoiding-re-creating-auto-generated-files

> Does "make touch" work for you as well?

Hadn't tried, and wasn't aware of its existence. I searched Makefile
for things like AST_H. Perhaps:

* Note "make touch" where the "A build now requires..." comment
exists. That comment currently discourages users, as it gives no idea
about the possibility of a workaround for a missing python.

* Add a comment to the touch target identifying its purpose.

It hadn't occurred to me to read the dev guide. That's for new
contributors, not for old, lapsed contributors. <wink> Also, it still
seems to me that the ASDLGEN definition should reference something
that is explicitly "Python 3" and can't accidentally execute a Python
2.x interpreter (or, the AST-generation script should work in both
Python 2.x and 3.x).

S

I ran into a (possibly) related compiling problem (for 'default', 3.5 branch) in `asdl.py`:

    class Module(AST):
        def __init__(self, name, dfns):
            ...
            self.types = {type.name: type.value for type in dfns}

The dictionary comprehension syntax means this can only be run with Python3.

With an older Ubuntu installation, python2.6 is my default 'python'.

I had to make a local `python3` link to an earlier development python3.4 to get around this.

Dict comprehensions actually work with Python 2.7 as well. I don't think making that part of the build process 2.6-compatible would bring us much.

Unless you're specifically modifying the Python syntax, you should be able to skip that part by running "make touch".

New changeset eefed1ecfd47 by Georg Brandl in branch '3.4':
Closes #21480: better explanation of "hg touch" in the Makefile.
https://hg.python.org/cpython/rev/eefed1ecfd47

asdl.py is fixed to work with 2.7 as of 3b2af26f4638.