[cairo] Flag for FP-challenged platforms

[Daniel Amelang]

On 11/30/06, Behdad Esfahbod <behdad at behdad.org> wrote:
> On Thu, 2006-11-30 at 14:40 -0500, Carl Worth wrote:
> >
> > I mean, we're talking about cairo wanting to select between different
> > code paths based on their performance characteristics. Why not just
> > have the build system compile, run, and measure both rather than
> > making the user decide?
> >
> > Insane?
>
> I'm all for it.  lets not clutter cairo's configure with gazillions of
> --enable options that most people don't even care about.  I'm all for

Eh, I personally think that these types of performance flags are so
few and far between that we don't have to worry about having a
'gazillion' options. But maybe you can forsee the future better than I
;)

> As for the heuristics, these come to mind:
>
>   - Running and measuring.  The least predictable, and doesn't work with
> most cross-compiling scenarios.

As pointed out by others, running a performance test at configure-time
is problematic, due to cross-compiling scenarios, so I vote no to this
idea.

>
>   - Switching on the host and other features that autoconf already knows
> about and/or our own observations.  Easy and predictable.  People will
> send in patches if it doesn't work for their scenario.

I fully support this idea. Although I don't think anything autoconf
knows will help us detect the floating point support of the target
system. But, it can be inferred from the compiler flags. For example,
we can detect the 770's lack of FPU by looking for #if
defined(__arm__) && !defined(__VFP__), and developers for similiar
systems can submit patches for their own architecture if they want the
same treatment (like the Maverick system that Koen mentioned eariler).

So I prefer this form of FPU detection, if any is used at all.

>
>   - Get CPU flags by way of /proc/cpuinfo or other means, ad see if an
> fpu is available.

This doesn't work for me in scratchbox, so I'm thinking it doesn't
work for cross-compilation in general.

Dan