bug#13170: automake and pyconfigure: a future integration?

[Stefano Lattarini]

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