[sword-devel] OS X/iPhoneOS based development

Manfred Bergmann manfred.bergmann at me.com
Tue Jun 15 00:14:26 MST 2010


Am 14.06.2010 um 22:57 schrieb Dmitrijs Ledkovs:

> On 14 June 2010 22:23, Manfred Bergmann <manfred.bergmann at me.com> wrote:
>> 
>> Am 14.06.2010 um 22:01 schrieb Dmitrijs Ledkovs:
>> 
>>>> For me I think it's time to switch now from manually build sword library to Xcode project because now the library is build together with the ObjC wrapper classes.
>>>> 
>>> 
>>> Fair enough. How are you keeping up with changes to sword? What is
>>> your xcode project layout?
>> 
>> I don't know about changes to sword. There are actually none. :)
> 
> Sorry, english is not native language here. I meant updates in sword -
> i.e. $ svn up
> 
> If there are more files added do you manually readd them in xcode to
> build sword from xcode?

Yes, you need to add them manually.

>> Xcode project includes the sword/src folder (minus some files that would not compile like all sources in frontend, dirent for win32 and such) and clucene as groups.
>> In build settings you add header file folders sword/include, icu, ... and linker flags for libcurl, libicu, ...
>> Finally you add CFLAGS actually the same as in makefile.
>> 
> 
> Meah =) i won't be able to do that for gtk, glib, pango, gtkhtml,
> xulrunner..... (i'm trying to nail xiphos build on mac)
> 
> 
>>> I didn't manage to make a project which can get have sword framework
>>> and xiphos getting pulled in from svn. I would also need Gtk, Glib,
>>> Pango and friends.... i have framework versions of those, but it's
>>> "imported" frameworks.
>> 
>> I'm not exactly sure what you mean?
> 
> to build xiphos i need sword, gtk, glib, gtkhtml, libxml at least. how
> would you go about defining all of these in the project.

Normally you build depending libraries via makefiles and them add them as link libraries to the Xcode project.
In the Xcode target you add a "Copy Files Phase" where you specify where that all files in this phase will go into the "framework" folder of the bundle.

> 
>> At the moment there is only one Xcode target that builds everything, together with Sword ObjC wrappers.
> 
> In the xcode project tree what is the difference between "executables"
> and "targets". I think i really don't understand what xcode means by
> "target".

A target could be compared with a makefile. You can have multiple targets in a project. The target type will define what the actual output is i.e. a command line tool or a cocoa application, or a framework.
Under products you will see then the product of the framework once it was build. The products have different icons depending on the target type.

>> It would make sense to split this to have a separate targets for the Sword dylib and wrapper.
> 
> what I'm trying to understand how to package all headers & dylib into
> universal framework. I've seen quite a few mac specific projects which
> ship framework and as far as I understand it uses some kind of weak
> linking and relocation code. these frameworks can either be in
> /Library/Frameworks, ~/Library/Frameworks or inside an app-bundle.

As said above you compile dependencies which are to complicated to build them in Xcode manually via makefiles. This sometimes is just easier as to try to get them built in Xcode.
Then in your framework target you add those libraries into "Link binary with libraries" phase and create a "copy files build phase" where you place all libraries which are supposed to be bundled in the framework. In the "Get info" of the "copy files build phase" you can choose what kind of type those files are or where they are supposed to be copied in the bundle. For libraries you would choose "framework".

> To
> top this off with one such package I was able to mix & match, i.e. it
> didn't matter where the framework was "thin" app-bundles continued to
> work, but bundles which had framework embedded inside them where as if
> statically linked and didn't take notice of the same framework
> installed in */Library/Frameworks.

Further in the build settings, specifically the "Installation Directory" setting you can choose where this framework will be installed.
If it should be an embedded framework which application will embed like I'm doing for MacSword then the framework will be embedded into the Application Bundle and you define "@executable_path/../Frameworks" on this setting.
Normally you need two types of framework. One embeddable and one that can sit in one of the *Library/Framework folders.
I don't believe an embedded framework will work outside of an application bundle.

> Ideally i'd like to be able to painlessly create pre-compiled
> sword.framework with dynlibs, headers & documentation compiled for all
> arches including iphone / iOS, throw it onto ftp.crosswire.org. Then
> anyone could grab it and start developing for mac or iDevices and e.g.
> xiphos and macsword could share it on the user's system saving space.
> (with an option to embed sword framework inside app-bundle as well)

> Is this what xcode calls target?

I believe making gtk and those other dependencies in Xcode will not be so easy. It should be doable but I would actually build them using makefiles.
But yes. You can define per target for which archs it should build.

> Ideally sword.framework would contain icu & curl but not expose those
> headers/symbols to prevent abuse =) (e.g. using sword.framework to
> build a freaky app which actually just uses icu). In otherwords make
> sword.framework self-contained, flexible and abi/api stable for
> everyone who ports or write apps for apple platforms.

icu and curl are part of the system and don't need to be compiled in the project you just add linker flags: -licu -lcurl.
But yes, that what you can do with frameworks, you can define which interfaces/headers are public and exposed and which should be private.




Manfred



More information about the sword-devel mailing list