[issue21242] Generalize configure check for working Python executable

2020-03-18 Thread Brett Cannon
Change by Brett Cannon : -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

[issue21242] Generalize configure check for working Python executable

2020-03-18 Thread Brett Cannon
Brett Cannon added the comment: `make regen-all` has probably taken care of this. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue21242] Generalize configure check for working Python executable

2017-01-07 Thread Martin Panter
Martin Panter added the comment: It is still not clear what change you were proposing. Perhaps factor out the common code for ADSLGEN and OPCODEHGEN? If so, that has been done as part of Issue 26662 in 3.5+. -- nosy: +martin.panter superseder: -> configure/Makefile doesn't check if "p

[issue21242] Generalize configure check for working Python executable

2014-04-15 Thread Brett Cannon
Brett Cannon added the comment: You figured out the reason for the interest; I filed the bug faster than Kushal could commit his code. =) -- ___ Python tracker ___ _

[issue21242] Generalize configure check for working Python executable

2014-04-15 Thread Meador Inge
Meador Inge added the comment: Ah, okay, this looks in reference to the opcode generation stuff in issue17861. -- ___ Python tracker ___ _

[issue21242] Generalize configure check for working Python executable

2014-04-15 Thread Meador Inge
Meador Inge added the comment: I am not sure I follow. In configure.ac I see one check for Python: AC_SUBST(ASDLGEN) AC_CHECK_PROGS(PYTHON, python$PACKAGE_VERSION python3 python, not-found) if test "$PYTHON" = not-found; then ASDLGEN="@echo python: $PYTHON! cannot run \$(srcdir)/Par

[issue21242] Generalize configure check for working Python executable

2014-04-15 Thread Brett Cannon
New submission from Brett Cannon: configure.ac has a check that sets ASDLGEN based on what Python interpreter to use for running various scripts which generate files related to the AST. It probably should be generalized so that there's only one check for any script usage in Makefile.pre.in sin