On 12/13/2012 03:14 PM, Brandon Invergo wrote: >>> 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. > Glad we agree on this.
> 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. > The nice thing is that such an integration would be mostly transparent to Automake in any case :-) >> 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? > That, and automake-patches. But consider that the percentage of python-related patches and reports there is reeeealy low. Maybe it's simpler if I just CC you and bug-pyconfigure in my replies to any python-related message on the Automake lists (and hope I won't forgot doing so). >> Well, at least those parts of Automake deals with python ;-) >> >> And I'm open to such a rewrite, it it will brings clear advantages; >> Er, s/it it/if it/ and s/brings/bring/. Sorry for the sloppiness. >> 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. > Thanks, Stefano