>> What happens in pyconfigure (more on that in a moment) is that you can >> pass an argument to AC_PROG_PYTHON. So if you want to use Python 2 >> specifically, you first search for it with AC_PROG_PYTHON([python2]). >> In a standard system, this should find the most recent Python 2 >> interpreter. >> > Would that also find a python 2.x interpreter names simply as "python"?
No, it would just look for one called python2. That said, I guess there's nothing stopping you from doing AC_PROG_PYTHON([python2 python]). Or, if you know you only want Python 2.5, 2.6 or 2.7: AC_PROG_PYTHON([python2 python2.7 python2.6 python2.5 python]). You can pass whatever arguments you want and it should work. No need to rewrite the macro (as this proposed patch in discussion apparently did). >> Here's an example configure.ac chunk to do that using Pyconfigure's >> macros: >> >> m4_define(python_min_ver, 2.5) >> > (Nit: missing quotes; should be "m4_define([python_min_ver], [2.5])") > More important, you define this as a m4 macro ... > ... but later use it a shell variable. What am I missing? Heh...actually, in the code there's no $ since it's a macro...I added the $ as I was typing my email because I guess my head is in shell mode right now and it looked wrong. Anyway, mentally erase that $...it's not there :) Thanks for the heads up on the quotes though; I'll fix that in my examples. > Note that for "integration" I didn't mean merging your project into > Automake, but rather, having Automake leveraging on the m4 macros > provided by it; as we do with, say, the 'LT_INIT' libtool-provided > macro, without needing nor wanting it to be part of the Automake > core. Got it. Let's say "interoperation". I agree. I picture Pyconfigure as sort of boilerplate Autoconf & Automake glue for Python projects. The upstream projects do what they do best, and I figure out how to make them as effortless as possible to use with Python. That said, the macros should still be merged into Autoconf eventually so that people don't *need* to depend on Pyconfigure as well if they don't want to. > I think that would go more smoothly collaborating with the upstreams > from the beginning; for example, we had some tweaks and bug-fixes > related to python support in Automake (see in particular the commits > v1.12.4-43-ge0e99ed and v1.12.5-14-g1f113f6 in the Automake's git > repository), and you might want to backport some of them into > pyconfigure as well. That's a good point. I'll check out those commits when I get home this evening. What would be the best way for me to stay abreast of relevant Python-oriented Automake changes? Which mailing list? bug-automake? > Well, at least those parts of Automake deals with python ;-) > > And I'm open to such a rewrite, it it will brings clear advantages; > e.g., better integration/compatibility with distutils, setuptools > and/or distribute (or what the python distribution subsystem du-jour > is, sigh), clearer semantics, etc. > No worry, once you have working rules, integrating them shouldn't > be difficult. In view of such integration, you might want to start > clearing copyright issues ASAP though (that is, signing FSF papers > for Automake contributions). Ok, well, I haven't even begun to tackle that part yet but I'll keep you guys informed of my progress. Cheers, Brandon
