Issue 13243: _Py_identifier should be _Py_IDENTIFER (original) (raw)
Created on 2011-10-22 06:38 by eric.snow, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (8)
Author: Eric Snow (eric.snow) * 
Date: 2011-10-22 06:38
Looks like Parser/asdl_c.py did not get all the way updated when _Py_identifier switched over to _Py_IDENTIFER. I've included a patch that fixes it (though it's relatively trivial). With this fix I did not notice any further problems.
Author: Meador Inge (meador.inge) *
Date: 2011-10-22 18:58
Good catch. I see what happened. 7109f31300fb updated Python/Python-ast.c but not Parser/asdl_c.py. I will apply your patch shortly. Thanks.
Author: Meador Inge (meador.inge) *
Date: 2011-10-22 19:03
Oh, and just to be clear I reproduced the build break by doing:
./Parser/asdl_c.py -c ./Python ./Parser/Python.asdl make
in a built tree. The reason that this wasn't caught is that the make rules have the ASDL files as dependencies on the AST C files. So, the C files are not updated unless the ASDL files are.
Maybe we should change the build system to always regenerate the files or add something to automation that regenerates the AST C file every time.
Author: Roundup Robot (python-dev) 
Date: 2011-10-22 19:12
New changeset 941d015053c6 by Meador Inge in branch 'default': Issue 13243: Rename _Py_identifier to _Py_IDENTIFIER in asdl_c.py http://hg.python.org/cpython/rev/941d015053c6
Author: Meador Inge (meador.inge) *
Date: 2011-10-22 19:14
Committed. Thanks!
Author: Martin v. Löwis (loewis) *
Date: 2011-10-23 12:26
Maybe we should change the build system to always regenerate the files or add something to automation that regenerates the AST C file every time.
Most definitely not. It is very deliberate that asdl_c.py is only invoked when the ASDL sources change. Otherwise, having Python installed would be a build requirement for Python, which it must be not.
Author: Meador Inge (meador.inge) *
Date: 2011-10-23 18:33
Most definitely not. It is very deliberate that asdl_c.py is only invoked when the ASDL sources change. Otherwise, having Python installed would be a build requirement for Python, which it must be not.
OK, thanks for the background. To be clear, though, the build dependency is already there. You just have to touch the ASDL sources to run into it (Lib/opcode.py as well). This is even documented in the Makefile*:
XXX Note that a build now requires Python exist before the build starts
ASDLGEN= $(srcdir)/Parser/asdl_c.py
However, modifying the ASDL source is, with respect to other source modifications, not as common. So, I see no reason to make the situation worse by running asd_c.py all the time. Suggestion withdrawn.
- If not relying on an external Python is a hard requirement (and I do see why that may be useful), then the build system could be changed to only allow changes to problematic sources (ASDL, opcode.py) after Python has been built once. Then the built Python could be used.
Author: Martin v. Löwis (loewis) *
Date: 2011-10-23 21:57
Am 23.10.2011 20:33, schrieb Meador Inge:
Meador Inge <meadori@gmail.com> added the comment:
Most definitely not. It is very deliberate that asdl_c.py is only invoked when the ASDL sources change. Otherwise, having Python installed would be a build requirement for Python, which it must be not.
OK, thanks for the background. To be clear, though, the build dependency is already there. You just have to touch the ASDL sources to run into it (Lib/opcode.py as well). This is even documented in the Makefile*:
Just to be more clear: normally, generated files shouldn't be checked into the source repository. However, exceptions are typically made for generated files that may be difficult to regenerate on some target systems. For Python, this includes configure (depends on autoconf being run), and various files generated from Python scripts (also including the Unicode database, for example).
So when we check in generated files, the build dependency becomes unused unless the source file gets modified - which, as you point out, happens rarely, and never happens for somebody who just wants to build Python.
- If not relying on an external Python is a hard requirement (and I do see why that may be useful), then the build system could be changed to only allow changes to problematic sources (ASDL, opcode.py) after Python has been built once. Then the built Python could be used.
See above. It's fine to require core contributors to have Python installed (and also autoconf). We just need to make sure that Python is not required on the target system (as people may try to install Python initially on that system).
History
Date
User
Action
Args
2022-04-11 14:57:23
admin
set
github: 57452
2011-10-23 21:57:23
loewis
set
messages: +
2011-10-23 18:33:24
meador.inge
set
messages: +
2011-10-23 12:26:42
loewis
set
messages: +
2011-10-22 19:14:28
meador.inge
set
status: open -> closed
nosy: - python-dev
messages: +
resolution: fixed
stage: patch review -> resolved
2011-10-22 19:12:35
python-dev
set
nosy: + python-dev
messages: +
2011-10-22 19:03:24
meador.inge
set
messages: +
2011-10-22 18:58:53
meador.inge
set
nosy: + meador.inge
messages: +
assignee: meador.inge
stage: patch review
2011-10-22 06:38:19
eric.snow
create