On 8/23/05, Philip Martin <philip@codematters.co.uk> wrote:
> > [[[
> > Require Python 2.0 or later for autogen.sh and configure. Look in the
> > following locations (in order) for Python 2.0 or better: $PYTHON2,
> > $PYTHON, python, python2
> >
> > * autogen.sh:
> > Use ./build/find_python.sh to find Python 2.0.
> > * configure.in:
> > (PYTHON): Use $srcdir/build/find_python.sh to find Python 2.0.
> > * build/find_python.sh:
> > New file. Look in the following locations (in order) for Python 2.0
> > or better: $PYTHON2, $PYTHON, python, python2
>
> You have written out the new order twice, something that is available
> by examining the code and so doesn't really need to be in the log
> message at all, but you haven't mentioned the change in the order.
> I'd use something more like:
>
> [[[
> Require Python 2.0 or later for autogen.sh and configure. Look for
> a suitable "python" command before "python2".
>
> * autogen.sh: Introduce PYTHON, use find_python.sh.
>
> * configure.in (PYTHON): Use find_python.sh.
>
> * build/find_python.sh: New.
> ]]]
Thanks! That's much improved. I've used your suggested log message.
> > Here's some examples to illustrate how the new code behaves:
> >
> > Scenario 1:
> > * "python" refers to Python 1.x
> > * "python2" refers to Python 2.2
> > -> We use "python2", because "python" is too old.
> >
> > Scenario 2:
> > * "python" refers to Python 2.2
> > * "python2" refers to Python 2.2
> > -> We use "python", because the user may have installed a local
> > version of python using the standard name "python", which they
> > want us to use instead of the system-wide "python2".
>
> That's a bit of dubious argument as far as I can see. My system
> doesn't come with a "python2" command ("python" is a Python 2). I
> could install a local "python2" to override the system's "python".
>
> "python2" used to have precedence over "python" and I think that makes
> sense, but I don't really care.
"python2" is a nonstandard name for the python executable, which is
used by some OS packagers. It's better to use the more standard
"python" executable, if the standard executable meets our needs.
Here's an example that shows why.
On my system, if I install "Python 2.4" to my home directory and put
it in my path, you'll find the following executables:
- python: Python 2.4
- python2: Python 2.2
Prior to my patch, Subversion tried to use the "python" executable for
autogen.sh, but then turned around and used the "python2" executable
for the Python/SWIG bindings. At the same time, the bindings used my
latest "Python 2.4" headers to build the bindings. As a result, the
bindings built used a weird hybrid of "Python 2.4" and "Python 2.2"
behaviour, and generated weird warnings.
> > +for x in "$PYTHON2" "$PYTHON" python python2; do
>
> PYTHON2 before PYTHON, but python before python2; doesn't that look
> odd to you? It needs a comment.
Good catch. I switched "python" to come before "python2", so it also
makes sense to put "PYTHON" before "PYTHON2". I've done this.
> > -# For compatibility with Subversion 1.1.3 and earlier,
> > -# which recommended setting PYTHON2, not PYTHON.
> You have deleted the reasoning for PYTHON2 to come before PYTHON.
Now that we have fixed "find_python.sh" to check the version of the
python interpreters it finds, there's no need to favour the
nonstandard "python2" and "PYTHON2" over the more standard "python"
and "PYTHON".
Committed in 15906. Thanks very much for your help, Philip!
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 25 20:08:59 2005