[Numpy-discussion] Numpy 1.3.0 rc1 OS X Installer

[David Cournapeau]

Christopher Barker wrote:
>
> I'm not surprised it took that long -- that sounds short to me!
>
> Anyway, If there are new python builds that are 64-bit (quad?) you wont' 
> have to change much -- "only" make sure that the libs you are linking to 
> are 64 bit. I suppose you could try to get a quad-universal gfortran.a 
> now, but I'd wait 'till you need it.
>   

My main concern was about making sure I always built against the same
python interpreter. For now, I have hardcoded the python executable to
use for the mpkg, but that's not good enough.
> It did a lot, but I don't THINK is re-compiled everthing. I think the 
> trick is that eveything it built was still in the build dir -- and it is 
> the saem python, even though it's not living in the same place.
>   

Well, yes, it could be a totally different, incompatible python that it
would still do as you said - distutils cannot be trusted at all to do
the right thing here, it has no real dependency system. The problem is
to make sure that bdist_mpkg and the installed numpy in virtual env are
built against the same python binary:
    - it makes sure the build is actually compatible
    - it also gives a sanity check about 'runnability' of the binary -
at least, numpy can be imported (for the doc), and by building from
scratch, I lose this.

Of course, the real solution would be to automatically test for the
built numpy - I unfortunately did not have the time to do this correctly,

> <key>IFPkgFlagDefaultLocation</key>
>
> which should be set to:
>
> <string>/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages</string>
>
> If it was built in a virtualenv, that would be the virtualenv path.
>
> It's a hack, but you could post-process the mpkg to change that value 
> after building.
>   

This has the same problem - it works as long as the virtual python and
the 'python targetted by the binary installer are the same'.

>
> showing what a pain all of this is! Of course, you could put it in:
>
> /Library/Frameworks/Python.framework/Versions/2.5/lib/site_packages/scipy/lib/
>
> or something that only scipy would know about.
>   

That's the only correct solution I can see, yes.

>> On
>> Linux, the static library is not even publicly available (it is in
>> /usr/lib/gcc/4.3.3). I wonder whether the mac os x gfortran binary did
>> not make a mistake there, actually.
>>     
>
> where are you getting that? I'm about to go on vacation, but maybe I 
> could try a few things...
>   

On linux, libgfortran.a is /usr/lib/gcc/i486-linux-gnu/4.3/libgfortran.a
-> this is private
On mac OS X, it is /usr/local/lib -> this is public

Exactly the kind of 'small' things which end up with quite some headache
when you care about reliability and repeatability.

As a related problem, I am not a big fan about the Apple way of building
fat binaries, I much prefer the approach one build/arch and merging the
binaries after build with lipo. This is more compatible with all
autoconf projects out there - and it means using/updating the compilers
is easy (building multi-arch binaries the 'apple' way is really a pain -
the scripts used by R, to build the universal gfortran, is quite
complicated). I think this above problem would not have happened with a
pristine gfortran built from sources,

cheers,

David