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.

Author meador.inge
Recipients eric.snow, loewis, meador.inge
Date 2011-10-23.18:33:24
SpamBayes Score 4.072569e-10
Marked as misclassified No
Message-id <CAK1QoorSrNnA8MJzHyyp+YAX_O7R7w1p0Zw44QJ9Q6Ttc9ZXkA@mail.gmail.com>
In-reply-to <4EA407FD.2080809@v.loewis.de>
Content
> 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.
History
Date User Action Args
2011-10-23 18:33:25meador.ingesetrecipients: + meador.inge, loewis, eric.snow
2011-10-23 18:33:24meador.ingelinkissue13243 messages
2011-10-23 18:33:24meador.ingecreate