bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake-1.11 test failure on darwin9 - instmany-python.test


From: Peter O'Gorman
Subject: Re: automake-1.11 test failure on darwin9 - instmany-python.test
Date: Thu, 21 May 2009 08:39:29 -0500
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Ralf Wildenhues wrote:
> Hi Matthias, Peter,
> 
> * Matthias Klose wrote on Thu, May 21, 2009 at 08:11:49AM CEST:
>> Peter O'Gorman schrieb:
>>> This patch works for me. Thoughts?
> 
>>> 2009-??-??  Peter O'Gorman <address@hidden>
>>>         m4/python.m4: Ensure that pythondir and pyexecdir are below
>>> ${prefix}.
>> why special case /usr and /usr/local? It undoes the effect that
>> get_python_lib *can* return something on it's own, which was the
>> intention of the original patch.
> 
> The logic is pretty intricate: the result of get_python_lib is taken
> into account
> - whenever it does not change the initial ($prefix) portion of the
>   directory, or
> - whenever it also changes the initial portion of the directory and
>   the --prefix passed to configure was /usr, /usr/local, or /System...
>   or defaulted.
> 
> That aims to ensure that if you do
>   ./configure --prefix=$HOME/local
> 
> as non-root user, you have a chance to actually install your python
> files below $HOME, too, even with the buggy python on that Mac OS X
> release.  Similarly with other --prefix values that clearly point
> outside of the normal system root: why should the python files be
> installed in system directories in that case?  If that would really
> be desired, then we should probably provide for a straightforward way to
> override the choices done by the macro.  (There is such an override now,
> but only at 'make all'/'make install' time, by overriding the related
> make variables.

Well, they are cache vars, so they can be overridden at configure time
too by doing ./configure ... am_cv_python_pythondir=/Somewhere/good etc.
I don't see the need to add a --with-foo configure option yet.

> 
> We could limit this patch to $am_cv_python_platform = darwin, but I'm
> not sure whether that would be necessary at all.
> 
> However, I have a few questions to the patch myself:
> 
> How come you added that /System/Library* thingy rather than just
> /System*?

Well, there is nothing below /System except for Library, but yes,
/System* would have the same effect. Note that /System, like /usr is
theoretically a vendor only area.

> 
> What about --prefix=/usr/ and similar variants?  The stripping of
> trailing slashes has only been added to Autoconf after 2.63.
> 

I don't care :) The only people doing ./configure --prefix=/usr should
be Apple engineers anyway.


> BTW, would excluding /usr/local even be desirable?  Can't there be a
> python hierarchy below /usr/local either?
> 

Yeah, I wasn't too sure about /usr/local, removing it (because people
may very well have installed newer python there) is probably a good idea.

> 
> I suggest a much more verbose ChangeLog entry, maybe something like
> 
>     python: do not install in system directories on Darwin 9.
> 
>     On Darwin 9, get_python_lib returns a path below `/Library/Python'
>     regardless of the `prefix' argument it was passed, causing `make
>     install' to target the system directories regardless of `--prefix'
>     argument used.  Work around this Darwin bug by ignoring the result
>     of get_python_lib if it points outside of the passed prefix, and
>     the prefix was not a system directory.
> 
>     * m4/python.m4 (AM_PATH_PYTHON): If the prefix does not match the
>     initial portion of the pythondir returned by get_python_lib, then
>     ignore it unless the configured prefix is `/usr', `/usr/local',
>     or starts with `/System/Library'.  Fixes instmany-python.test
>     failure on Mac OS X 10.5.7.
>     * NEWS: Update.
> 
> and maybe for a NEWS entry
> 
> * Long standing bugs:
> 
>   - On Darwin 9, `pythondir' and `pyexecdir' pointed below `/Library/Python'
>     even if the `--prefix' argument pointed outside of a system directory.
>     AM_PATH_PYTHON has been fixed to ignore the value returned from python's
>     `get_python_lib' function in that case now.
> 
> 
> WDYT?

Excellent!.

Peter
-- 
Peter O'Gorman
http://pogma.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]