This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: A build now requires...
Type: Stage: resolved
Components: Devguide Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: eli.bendersky, ezio.melotti, georg.brandl, paul.j3, pitrou, python-dev, skip.montanaro
Priority: normal Keywords:

Created on 2014-05-12 15:56 by skip.montanaro, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (8)
msg218324 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2014-05-12 15:56
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/ ./Lib/ ./Include/opcode.h
/opt/TWWfsw/bin/gmkdir -p Include
python ./Parser/ -h Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "./Parser/", line 1312, in <module>
    main(args[0], dump_module)
  File "./Parser/", line 1251, in main
    if not asdl.check(mod):
  File "/home/skipm/3rdParty/python/cpython/Parser/", line 183, in check
    v = Check()
  File "/home/skipm/3rdParty/python/cpython/Parser/", line 140,
in __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/ $(srcdir)/Parser/
# XXX Note that a build now requires Python exist before the build starts
ASDLGEN= python $(srcdir)/Parser/

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
	touch $(AST_H) $(AST_C)
msg218328 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-05-12 16:09
Does "make touch" work for you as well?
msg218331 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2014-05-12 16:13
Skip, PTAL at the devguide.
msg218332 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2014-05-12 16:27
> 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).

msg225844 - (view) Author: paul j3 (paul.j3) * (Python triager) Date: 2014-08-24 22:37
I ran into a (possibly) related compiling problem (for 'default', 3.5 branch) in ``:

    class Module(AST):
        def __init__(self, name, dfns):
            self.types = { 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.
msg225891 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-08-25 19:10
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".
msg228676 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-10-06 12:58
New changeset eefed1ecfd47 by Georg Brandl in branch '3.4':
Closes #21480: better explanation of "hg touch" in the Makefile.
msg228677 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-10-06 12:58 is fixed to work with 2.7 as of 3b2af26f4638.
Date User Action Args
2022-04-11 14:58:03adminsetgithub: 65679
2014-10-06 12:58:57georg.brandlsetnosy: + georg.brandl
messages: + msg228677
2014-10-06 12:58:46python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg228676

resolution: fixed
stage: resolved
2014-08-25 19:10:15pitrousetmessages: + msg225891
2014-08-24 22:37:44paul.j3setnosy: + paul.j3
messages: + msg225844
2014-05-12 16:27:14skip.montanarosetmessages: + msg218332
2014-05-12 16:13:14eli.benderskysetmessages: + msg218331
2014-05-12 16:09:49pitrousetnosy: + eli.bendersky, ezio.melotti, pitrou
messages: + msg218328
components: + Devguide
2014-05-12 15:56:38skip.montanarocreate