[SciPy-Dev] Drop i386 part of OSX wheel build?

[Matthew Brett]

Hi,

We're running into travis-ci time limits when building OSX wheels:

https://travis-ci.org/MacPython/scipy-wheels/builds/204105101

The main reason for this is that, for OSX, we are building twice,
first for i386, then for x86_64, and then combining these builds into
a 'fat' binary to be compatible with either architecture. The builds
take a long time, hence the timeout.

I believe that the i386 architecture on OSX is pretty much unused now.
For example, it looks like south of 0.5% of CPUs running OSX cannot do
64-bit:

https://www.adium.im/sparkle/#cpu64bit

I propose that we drop the i386 part of the scipy build, but continue
to distribute apparently dual-arch wheels (architecture 'intel') so
that the wheel installs into the Python.org and System Python builds
[1]. This has the added advantage of making the wheel build process a
lot simpler.

Thoughts?

Best,

Matthew

[1] https://bitbucket.org/pygame/pygame/issues/300/os-x-wheels-dmg-and-zip-builds-with-travis#comment-29275485

[Olivier Grisel]

+1

[Ralf Gommers]

Post by Matthew Brett
Hi,
https://travis-ci.org/MacPython/scipy-wheels/builds/204105101
The main reason for this is that, for OSX, we are building twice,
first for i386, then for x86_64, and then combining these builds into
a 'fat' binary to be compatible with either architecture. The builds
take a long time, hence the timeout.
I believe that the i386 architecture on OSX is pretty much unused now.
For example, it looks like south of 0.5% of CPUs running OSX cannot do
https://www.adium.im/sparkle/#cpu64bit
I propose that we drop the i386 part of the scipy build, but continue
to distribute apparently dual-arch wheels (architecture 'intel') so
that the wheel installs into the Python.org and System Python builds
[1]. This has the added advantage of making the wheel build process a
lot simpler.
Thoughts?

Sounds like a good idea to me.

Ralf

[David Cournapeau]

FWIW, we dropped osx 32 bits a few years ago at Enthought and nobody
complained

Post by Matthew Brett
Hi,
https://travis-ci.org/MacPython/scipy-wheels/builds/204105101
The main reason for this is that, for OSX, we are building twice,
first for i386, then for x86_64, and then combining these builds into
a 'fat' binary to be compatible with either architecture. The builds
take a long time, hence the timeout.
I believe that the i386 architecture on OSX is pretty much unused now.
For example, it looks like south of 0.5% of CPUs running OSX cannot do
https://www.adium.im/sparkle/#cpu64bit
I propose that we drop the i386 part of the scipy build, but continue
to distribute apparently dual-arch wheels (architecture 'intel') so
that the wheel installs into the Python.org and System Python builds
[1]. This has the added advantage of making the wheel build process a
lot simpler.
Thoughts?
Best,
Matthew
[1] https://bitbucket.org/pygame/pygame/issues/300/os-x-wheels-
dmg-and-zip-builds-with-travis#comment-29275485
_______________________________________________
SciPy-Dev mailing list
https://mail.scipy.org/mailman/listinfo/scipy-dev

[Sturla Molden]

Post by Matthew Brett
The main reason for this is that, for OSX, we are building twice,
first for i386, then for x86_64, and then combining these builds into
a 'fat' binary to be compatible with either architecture. The builds
take a long time, hence the timeout.

With only amd64 (x86_64) we can also use a recent gfortran to build
SciPy, e.g. a binary from the GCC wiki.

Sturla