Re: automake and pyconfigure: a future integration?

[Brandon Invergo]

>> 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