[SciPy-user] building 64bit scipy
Mon Apr 20 12:08:57 CDT 2009
On Tue, Apr 21, 2009 at 1:25 AM, Dan Yamins <email@example.com> wrote:
>> Just copy and paste the given command in the terminal - or better,
>> install numpy first from svn, so that you don't need any other
> So I did try to do this. But the command fails if you first put "sudo" in
> front of it.
Yes, sudo affects environment variables.
> But I have a few questions:
> a) the syntax of that command that you gave me is new to me.
It is simple: you just set environment variables which are imported
and interpreted during the build process.
> I'm not an
> expert in make files, and I don't really instand the way that the scipy
> setup.py module commands interact with the setting of compiler flags.
They interact in a non standard manner. setup.py drives the build
through a package called distutils, which is used by the majority of
python packages out there (setuptools is a set of extensions on top of
distutils). Unfortunately, it does not work the same as the standard
configure/make/make install, and on top of it, we (numpy/scipy) use
our own extensions which also add some complexity.
> wouldn't have known how to put together a command like this -- where would I
> look to learn about this? Is it a make file thing?
There is no make file in scipy or numpy.
> c) Why would having built numpy from the svn have avoided the need for
> this? Is there something different about the way that that numpy retains or
> exposes information about the compiler flags that were used to build it?
Because distutils is not enough to build numpy and scipy (very few
packages in python community needs fortran support, for example, so we
needed to add this). So we have our own extensions in numpy - IOW,
scipy requires numpy.distutils to build correctly. FOllowing your
email, I added the necessary code to support intel 64 bits in
numpy.distutils, which would be in turn used by scipy.
Unfortunately, there is no easy way to just modify one flag in the
build process as is the case with the usual (and much better)
More information about the SciPy-user