[103464] trunk/dports/math/atlas/Portfile

[Rainer Müller]

On 2013-02-27 08:53, Vincent Habchi wrote:
> True, but there is no PPC buildbot AFAIK, and that’s the only case of
> mono-processor Apple machines; even the first x86 machines were
> CoreDuo based, if I’m not mistaken. We already have debated about
> Atlas – personally, I think the best solution would be to disable
> binary download altogether, since the code is so closely tied to the
> underlying hardware. It doesn’t make sense to use code built for
> another CPU because it can be under- or over-optimized.

Personally, I think that there is no benefit from building our own
atlas. The Accelerate.framework shipped with Mac OS X is optimized for
the hardware shipped by Apple - isn't that enough? I am still using
-atlas in variants.conf for my installations (a relict from the times
before we had binary archives).

Building a version of atlas tailored for the current machine is out of
the scope of MacPorts in my opinion – that would require -march=native
and a higher optimization level than our default of -O2.

If we now even have to force building from source for the atlas port,
that is one reason more to make the -atlas variant the default for
py-numpy, py-scipy...

Note that atlas is not exclusively used for scientific computation.
Through dependency chains such as py-pygtk or py-cairo it is pulled in
by other software, e.g. inkscape or gimp for image manipulation. Users
of these ports most probably don't care about a highly optimized atlas.

>> This should be selectable by variant. There should be two
>> mutually-conflicting variants, and which one is default should be
>> selected based on your check above. The buildbots are
>> multiprocessor so they will build the multiprocessor version; if a
>> user has a single CPU then they'll build that on their own
>> machine.
> 
> The threaded version of Atlas won’t build on mono-processor machines
> because OpenMP denies the creating of threads and Atlas raises an
> assertion. So the choice if somehow forced. Besides, on multicore
> machines, both serial and threaded version are built…

If the threaded version is an addition over the serial version, then
this should be a single +threaded variant.

The default_variants could be selected automatically, such that
+threaded is used for multiple cores and -threaded if only a single CPU
is installed. Furthermore, the selection of variants could be validated
against the current machine and raise an error if +threaded is selected
on a mono-processor computer as that would lead to a build error.

This would still allow to create binary archives without breaking the
build process for systems with a single CPU only.

Rainer