[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

XCode - Notes and Instructions (was Re: [XaraXtreme-dev] setup.h and configuring wxWidgets)



On 12/08/06, Alex Bligh <alex@xxxxxxxxxxx> wrote:
Ben,

...
>> The advantage of the X-Code project mechanism is that it is far
>> easier to build a universal binary that way.
>
> So at some point Official builds will have to be made using the XCode
> project mechanism.

Not necessarily. The official builds are made in an automated manner
and I have no idea how easy it is to automate XCode building. You
can build a UB just by building both versions (which can be done
from ./configure etc.) and then use lipo to stick them together.

XCode is very easily automated. I imagine that the whole of the Tiger
and Leopard deliverables were produced that way. A good working
example is the Cyberduck project http://cyberduck.ch/ and Abiword
(last time I looked the Abiword trunk had some changes incompatible
with the MacOS).

Yes, you can construct a UB using lipo to stick together a PPC and an
i386 version (this is how the latest release of Inkscape was done),
but you need to take some care to be sure that the versions and
library dependencies are identical, and I would not advise it if there
a realistic chance of using the Apple methods which have been tested
by Apple!

BTW, terms like 'Personal Build', 'Debug Build', 'Development Build',
'Release Build', 'Official Build', 'Nightly', 'Retail Build', whilst
they may overlap in part, have specific meaning to me. Thus, if
someone has a development machine that he or she could devote to this
project, then by downloading the matching source tarball, and
following the official instructions that person should be able to
obtain a deliverable byte for byte identical with the 'Official Build'
- one that Xara could stand behind.

...
> Logically, if 'first timers' need the XCode project for the 'one step'
> advantage and 'Official builders' need it for UB support then this
> mechanism ought to be given some sort of priority. I have to admit
> that the convenience advantage of the command line methods to someone
> working on just their own part of the project had rather blinded me to
> this!

Oh sure. I am not arguing "don't use XCode to build camelot". I am
responding to your point that editing setup.h etc. is fiddly, and
Phil's point that it is yucky. [good stuff snipped]

You are  bit ahead of me, I am really only concentrating on the point
that we do not seem to be able to get a Mac Xara LX in front of any
Xara artists; and this at a time when the Linux Xara LX is usable -
artists are able to switch away from Microsoft windows for their
graphic work and in fact switch away from Microsoft windows
altogether.

...
Fortunately, this is now largely an argument about how we write
the build instructions, ...

(I agree). That doesn't quite get me off the hook, as I did say,
months ago, that I would contribute to the page
http://www.xaraxtreme.org/developers/documentation/xara_lx_mac_build_instructions.html
, and I am still thinking about how to deal with the png, jpeg, z and
xml libraries!

I do look forward to gaining a complete insight into compiling an
Official Xara LX with XCode so that the Instructions can contain that
information, perhaps instead of the command line version.

Ben