Handling packages with SSE extensions

[Quentin Spencer]

Tom 'spot' Callaway wrote:

>On Wed, 2005-08-17 at 12:47 -0500, Quentin Spencer wrote:
>
>  
>
>>ATLAS doesn't do this. It is based on compile-time optimizations (that 
>>make for very long compiles). Because the resulting binaries are 
>>hardware dependent, I'm using the Debian package as a starting point 
>>because it uses a scheme of "recorded builds" from "average" hardware to 
>>produce binaries that are repeatable regardless of hardware and perform 
>>reasonably well on a range of hardware. Some additional performance 
>>improvement can be obtained if a user rebuilds a custom package for 
>>their system. The ATLAS sourceforge site distributes separate binaries 
>>for all of the different SIMD extensions, and I don't see this changing. 
>>I was hoping to put all the separate extensions in separate packages and 
>>have the user install the correct one (or find a way for yum to find the 
>>correct one), like is done with the different kernels. This is a very 
>>tricky packaging problem, and I welcome any suggestions on how best to 
>>deal with it.
>>    
>>
>
>Well, I'm not that familiar with ATLAS, but you might be able to resolve
>it like this:
>
>Assuming that on i386, it can generate multiple binary files for SSE,
>SSE2 and 3Dnow optimizations.
>
>Loop through all possible optimizations, and generate sets of binaries
>that are named appropriately (e.g. atlas-sse, atlas-sse2, atlas-3dnow)
>
>Generate a program that detects which optimizations the hardware is
>capable of using.
>
>In %files, %ghost the expected binary name. Then, in %post, run the
>detection program and use the output to symlink the best optimized fit
>to the expected binary name.
>
>The downside to this approach is that you end up with a lot of extra
>binaries on the system that can't be used (or perform sub-par). :/
>  
>

Thanks for the suggestions. Now one more related question: suppose as I 
alluded to earlier that we have an SRPM that rebuilds predictably on any 
system but I want to add an option for a user to do a custom RPM for 
their own hardware. What's the best way to do that? I was thinking along 
the lines of adding something in the spec file that triggers a custom 
compilation when some special switch is added to the rpmbuild command.

-Quentin