[sword-devel] OS X/iPhoneOS based development

[Greg Hellings]

On Mon, Jun 14, 2010 at 5:52 PM, Dmitrijs Ledkovs
<dmitrij.ledkov at ubuntu.com> wrote:
> WOW
>
> I'm not quite sure but it's either CMake is amazing or Xcode is
> amazing or both of them totally rock. And probably Gregory for doing
> awesome job in doing this port.

Dmitrijs, glad to hear you're finding it useful!  You're the first
feedback I've received regarding it, so it's always nice to get
feedback, especially if the first feedback is positive!

>
> it looks like it is doing out of the tree builds so i can have
> Makefile cmake generator in one dir and xcode generator in another dir
> and use them by mix and matching.

This comes as a minimal-effort feature of CMake and is encouraged as
the preferred way to work with CMake.  That way, if something goes
wrong during configuration or build you easily just rm -rf the
offending directory and start from scratch if you can't rectify the
situation.  For SWORD I made out-of-tree mandatory with CMake.

>
> From faq of cmake there are loads of simple parameters you can set to
> get it xcode projects for any arches/sdk's you want/need.

I have included build/configuration files for a number of the
different iPhone SDK packs with help from
http://sites.google.com/site/michaelsafyan/coding/resources/how-to-guides/cross-compile-for-the-iphone/how-to-cross-compile-for-the-iphone-using-cmake.
 The so-called "architecture files" that can be set with either the
CMake GUI or command-line arguments are found in the cmake/toolchains/
directory.  When I tested, they worked for all the 3.0+ versions that
you see in that directory.  Hints for what command-line arguments to
use can be found in cmake/configure-iphone.sh and
cmake/configure-iphone-simulator.sh.  I don't know how well the
resulting libraries will work, but I do know that I have made them
compile in Xcode using those settings.

>
> Furthermore the generated xcode project is in subdir but it doesn't
> copy over source files instead they are referenced to the source dir
> from where cmake was run. So anything I edit in xcode is editing the
> svn checkout.

The same goes for Visual Studio and Unix makefile builds with CMake
(and, I would presume, any other systems CMake supports that are
capable of it).  It makes it very nice if you have multiple
configurations (e.g. Mac OS X, iPhone Simulator and iPhone Device) in
3 different directories and you want to test how a single change would
affect all three, etc etc.  A very nice feature, indeed!

>
> The source tree in xcode project looks about the same as the checkout.
> But the targets are structured wonderfully. You get the dynlib target,
> when you click on it it shows all the source files which are needed to
> build that target only. And every single little tool has it's own
> target and it depends on libsword target and lists only it's own
> sourcecode. Naturally there is the almightly "build everything" target
> =)

It will even generate a "make install" or equivalent on platforms that
even remotely support it (OS X, Linux, Windows, etc).

>
> The best bit is probably that the xcode project is linked back to
> cmake. Each target has pre & post rule in xcode to talk back to cmake
> and reconfigure on the fly.
>
> And finally the actually compile uses Xcode built-in rules so I get
> all xcode features, as if I defined the xcode project from scratch /
> by hand. So i get xcode precompiled headers, pre-binding, caching and
> parallel builds and can run debugger, DTrace and all that jazz against
> it.
>
> If CMake does the same for Visual Studio then hands-down cmake rocks
> and sword really needs it if we want to seriously push into mobile
> device.

CMake does the same for Visual Studio and Unix makefile projects, even
down to the point of auto-reconfiguring if one of the CMake files has
changed since the last time a file was loaded.  The only awkward spot
is in Visual Studio the build needs to stop after the auto reconfigure
and the user is prompted to reload the project because the file has
changed on disk.  For makefiles they're smart enough to pick up the
changes directly (that was in 2.6 - version 2.8 might have fixed that
awkward step in Visual Studio).  I see this as one of the biggest
improvements over autotools from a user's experience - even if you
don't remember the full steps of autoheader/autoconf/automake/etc,
CMake will remember that for you if you modify the CMake files!  I
know it would save me untold grief while tracking the SVN head of a
project after a change to the autotools if they would just detect and
reconfigure themselves.

All-around I was hoping that the CMake build system could, even if it
doesn't ever replace the autotools, at the very least remove the need
to manually maintain different versions of Borland, Visual Studio,
Eclipse and Xcode (and more?) project files in the tree.  I know it
supports all of those and more.

>
> I think it will be easy enough to create my dream sword.framework
> using this, since by the looks of it I'll just define a separate
> project, import the library from this cmake-xcode project and play
> around with it to turn in into a framework. Although I'm gonna start
> with cmake first cause probably we can tweak it into turning
> sword.dynlib into framework =)

I'd be happy to work with you on doing anything like that you need.  I
don't know too much about creating Frameworks or building the
bindings.  I believe the current state of the CMake project files has
feature parity with the autotools in building the library, utilities,
demos and tests but I hadn't touched the bindings yet, because I had
no idea how those are built.  Also, I wanted to get feedback from
others on how well the current base abilities were working for them.

Feel free to push a new branch to Launchpad if you have fixes or
additions or to mail me patches or anything else like that.  I can
also be found on IRC many days, though depending on work and such I
might be more or less available.

--Greg