[Numpy-discussion] Numpy 1.3.0 rc1 OS X Installer

[Christopher Barker]

David Cournapeau wrote:
> 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,

quite true -- though hopefully you now what is on your system, so it can 
only go so wrong.

However I just noticed that in a brand new virtualenv, there is 
".Python" file, which is a symlink to:

/Library/Frameworks/Python.framework/Versions/2.5/Python

So you may be able to use that to ensure that the python you build the 
.mpkg with is the same as the one in the virtualenv.

>     - it also gives a sanity check about 'runnability' of the binary -
> at least, numpy can be imported (for the doc)

but it may not help with that.


I think some of this could be improved by hacking bdist_mpkg, but 
someone would have to find the time to do that.

It's still going to be a pain until core python supports some kind of 
versioning or virtualenv system, and all the tools then support that.

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

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

so maybe the above could help.

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

So it's that or static libs -- I don't understand what the static lib 
problem is, so I'm not help there.

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

I meant where did you get/how did you build gfortran in the first place. 
Are you using this one?

http://r.research.att.com/tools/

They seem to be quad-architecture and have the static libs -- I haven't 
tried to build anything with it yet, though.

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

I don't know -- the biggest issues I've seen are with build systems that 
assume you are building for the architecture you are on, which would 
break either way, unless you build each piece on a different machine.

I just discovered that mac port now support building Universal libs for 
at least some packages -- when it does, it seems to work great. NO 
gfortran, though....

I hope some of this helps.

I really appreciate all you've done on this,

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov