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-build...
On Sat, Feb 25, 2017 at 7:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
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?
Sounds like a good idea to me. Ralf
FWIW, we dropped osx 32 bits a few years ago at Enthought and nobody complained On Fri, Feb 24, 2017 at 6:51 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
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 _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
On 24/02/2017 19:51, Matthew Brett wrote:
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
participants (5)
-
David Cournapeau -
Matthew Brett -
Olivier Grisel -
Ralf Gommers -
Sturla Molden