[sword-devel] OS X/iPhoneOS based development

[Dmitrijs Ledkovs]

On 15 June 2010 14:27, Greg Hellings <greg.hellings at gmail.com> wrote:
> 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/

What's CMake GUI? and where do I get one?


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

The idea about bindings is:

1) Build sword library and headers
2) Take bindings pixy dust (swig) and run swig to regenerate itself
against sword library
3) Take the output from swig and compile the bindings (e.g. python
module) install & use

I don't know how many swig bindings are currently in working/updated
state. If you find any CMake/swig info please post links =)

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

lp:sword/cmake now points to your branch =)

> --Greg
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>