On the xcode-users mailing list, a discussion has started around building a universal binary for SQLite. I’ve been working on my low level database engine for my application and SQLite is at the heart of it. For the past several days, I’ve been working on how to build and package it. As I read this thread, I realized I need to find a way to get the universal binary into the app.
One suggestion from Marco Bambini was to do a simple edit to the Makefile generated by configure. His solution appears to work very well. It is the advice given in Apple’s Unix Porting Guide. However, I would like to distributed part of my engine as a Cocoa framework that has some Objective-C objects around SQLite. I wanted a little more than just hacking the Makefile. So I came up with a patch to the configure.ac file. This seems to mostly work. It works as follows:
patch sqlite/configure.ac sqlite-autoconf-macosx.patch
autoreconf
configure –enable-macosx-universal –disable-shared
I’m not convinced that I have done this right but it is producing a fat binary. Some other references on the list were made that the libtool isn’t right and that endian-ness may be a problem if SQLite isn’t correctly coded. I’ll have to test it out some more. But it did get me thinking about how can autoconf/GNU tool chain correctly support platforms that produce fat binaries? Autoconf in my opinion is a complex thing to build. It is extraordinarily time consuming to create the chain of files. It does however do a great service by making code portable.
The SQLite code base is pretty small so it might not be so bad to create a full native Xcode project around it. I think I’d have to reproduce all the steps in the Makefile though - including invoking the lemon parser.
Post a Comment