GNU bug report logs - #13170
automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

Previous Next

Full log

View this message in rfc822 format

From: Brandon Invergo <brandon <at> invergo.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13170 <at> debbugs.gnu.org, bug-pyconfigure <at> gnu.org, jack <at> jackkelly.name, automake-patches <at> gnu.org, mail <at> kerrickstaley.com
Subject: bug#13170: automake and pyconfigure: a future integration?
Date: Thu, 13 Dec 2012 15:14:16 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.