[cairo] Compile Mac OS X universal binary of cairo

[Michael Sweet]

Daniel Amelang wrote:
> ...
> 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.

No, I am proposing that *in addition to* the current autoconf
test, you provide a few preprocessor conditionals for Mac OS X
(a significant platform) so that we can more easily use and
deploy Cairo there.

The current solution requires 4 separate builds to provide Cairo
on both PowerPC and Intel-based Macs (32-bit and 64-bit for each).
The Mozilla build system hack of using Rosetta to compile PPC code
on an Intel system cannot work for 64-bit builds, so you are forced
to do builds on two systems and then combine the result.

Now, if I have to build Cairo-based software on the Mac, I will
maintain my own branch that contain the preprocessor directives
that allow me to build all 4 architectures on one system.  A pain,
to be sure, but less of a pain than combining the results of 4
separate builds.

> ...
> 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.

Apple is not recommending one method over another.  *If* the software
can be built without using lipo separately, they fully support doing
so (and that's how CUPS is built at Apple, BTW...)  The only time
you *must* use lipo is when you have software that is not smart
about its endian assumptions or when you want to build software
based on different SDKs (Mozilla ships with 10.2.x PPC + 10.4.x Intel
fat binaries, for example).

Under the covers, Apple's GCC uses lipo when you specify multiple
architectures to combine the intermediate object files into the
target file for you.  Aside from the convenience factor, this
feature also makes sure you are building the software a) from
the same source files, b) using the same compiler, and c) using the
same SDKs/frameworks.

> 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.

Unless you need extreme performance optimizations like Cairo, there
is no reason why source code can't be endian-neutral, allowing for
multiple-architecture builds.

In our build farm, we currently build CUPS, CUPS DDK, EPM, ESP
Ghostscript, FLTK, Gutenprint, HP IJS, HTMLDOC, libjpeg, libpng,
libtiff, Mini-XML, OpenLDAP, OpenSLP, OpenSSL, RasterView, zlib,
and our commercial software 2-way fat on Mac OS X using the -arch
options (no lipo, 1 build directory).

The *only* software that needed any tweaking was HP IJS, which
uses endian-specific optimizations in the color matching code.
All I needed to do was add a few conditional directives to the
config file to resolve that issue.

You've already taken on a lot of maintenance burden for all of the
platform-specific performance optimizations in Cairo.  Adding a few
conditional directives to the config.h header isn't, IMHO, any more
onerous, and will ensure that the definitions you use for word order
are applied consistently and correctly in the actual code.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com