[Numpy-discussion] RPMs out of date, have problems

gvermeul at labs.polycnrs-gre.fr gvermeul at labs.polycnrs-gre.fr
Sun Jan 6 06:48:05 EST 2002

> > python setup.py bdist_rpm needs only write access to the user's home
> > directory.
> Everywhere? It didn't when I first tried (that was an early distutils
> release under RedHat 6.2).
Can you check which version of Python/distutils. If it is a version python
that does not come with distutils, we can count it out.
> > Of course, adding a generic spec file is the easy 2 minutes solution,
> > but I have choosen not to do that because it will invite bad policy
> > (providing binary RPMs is asking for trouble).
> And yet many people will not accept anything but binary RPMs, out of
> ignorance or fear. We won't make everyone happy...
Yes, and they will complain to JH if they are failing to install JH's
binary RPMs. The best we can do is explain the motivation of NOT
providing binary RPMs. If that is not sufficient for some, we can
only advise that they switch to Windows or pester their distro
providers for RPMs of the latest NumPy.
> I admit that I never looked into fully automatic RPM generation by
> distutils as I usually need to add some manual steps to the
> build/install process. For example, distutils doesn't let me specify
> compiler options, but I want time-critical code to be compiled with
> the highest optimization level. Hopefully this will be addressed in
> distutils one day.
There are two ways to do this:

(1) Extension( ..., extra_compile_args = [ "-O17" ], ...)
This will append the optimization level 17 to the compiler flag
(the last -O option counts).

(2) export CFLAGS=-O3; python setup.py build
This will append -O3

The result of (1) and (2) is gcc .... -017 -03


PS: distutils may look intimidating at first, but it is really
simple compared to automake/autoconf. The disadvantage is that
it is not very well tested.

This message was sent using Endymion MailMan.

More information about the NumPy-Discussion mailing list