[cairo] Compile Mac OS X universal binary of cairo

[Daniel Amelang]

On 2/6/07, Michael Sweet <mike at easysw.com> wrote:
> Carl Worth wrote:
> > On Tue, 06 Feb 2007 11:03:19 -0500, Michael Sweet wrote:
> >> This sort of problem is exactly why I advocated against a configure-
> >> time endian check when this code was added
> >
> > What do you suggest as a replacement?
> >
> >> and then tried to get at least a special case made for Mac OS X.
> >
> > What would the special case look like?
>
> Here is the original thread where I mentioned this:
>
>      http://lists.freedesktop.org/archives/cairo/2006-October/008285.html
>
> and my example (which would just need to be modified accordingly
> for the stuff you are defining for word order):
>
>      http://lists.freedesktop.org/archives/cairo/2006-October/008292.html
>
> Bill Spitzak also posted a response indicating that __BIG_ENDIAN__
> is defined when compiling PPC or PPC64:
>
>      http://lists.freedesktop.org/archives/cairo/2006-October/008297.html
>
> which would reduce the conditional code to:
>
>      #ifdef __BIG_ENDIAN__
>      ... force big-endian usage ...
>      #elif defined(__APPLE__)
>      ... force little-endian usage ...
>      #endif

To be clear, you are proposing that we abandon using the
(platform-independent) autoconf-based approach for detecting the
properties of the underlying system and that we generate our own
platform-dependent special case code based on compiler symbols. In
addition, you proposing (indirectly) that we split the responsibility
of feature detection into two places, depending on platform.

Either way, we are making Cairo a little harder to maintain in order
to work around a limitation of autoconf. Maybe that's OK, but we need
to get all this out in plain sight to make a good decision.

I think that is it important to see what Apple advises developers to
do about building universal binaries for configure-style projects:

http://developer.apple.com/technotes/tn2005/tn2137.html

"While the GNU Hello program is one of the most complicated "Hello,
World" programs ever written, it is still a relatively simple program:
it does not care about byte order, word size, or pointer size; nor
does the configuration process generate any executables which
themselves produce configuration files based on the machine target.
Not all Open Source projects are this simple. For them, there is
another approach, which involves using the lipo command."

>From what I can tell, you are proposing that we stray from our
established means of platform feature-detection so the developer can
stray from the recommended means of building a universal binary.

Now, let's assume that the Right Thing To Do is special case the
features in question in the cairo config.h file. This would imply that
all autoconf-based software should now be special casing any features
that aren't currently handled by the configure mechanism when building
a universal binary. It's hard for me not to suggest that the problem
should be solved at the build-tool level, not in each and every
software project.

Dan