[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
[XaraXtreme-dev] XCode - The main goal ( was Re: Concerning wxrc)
- From: "Ben Fowler" <ben.the.mole@xxxxxxxxx>
- Date: Mon, 26 Jun 2006 12:46:57 +0100
- Subject: [XaraXtreme-dev] XCode - The main goal ( was Re: Concerning wxrc)
On 14/06/06, Phil Martin <phil@xxxxxxxx> wrote:
[ snip ]
... the main goal of simply getting the application to build reliably.
On Saturday, using an XCode-personal project (see previous), I built
r1355 and it passed my current smoke test which is to open Garden.xar,
select and move a large number of objects, and delete them.
(My previous smoke test was to make a new document, this fails with a
message about the need to create a template - I dare that this is by
I can certainly provide you with a diff for the project.pbxproj file
within the project, IIRC it is about 55kbyte in size, and so you might
be very reluctant to apply it and therefore consider time spent
studying it to be wasted. In brief, what needs doing is:
1. Fix up paths for wx include files
2. Remove a few paths that are specific to your system
3. Change settings to 'Current' (instead of SDK)
4. Add a libxml library
5. Create and build a wxXtra target
6. Add a few files to the XaraLX target
7. Add a few files to the project
That is all the heavy lifting that I believe to be necessary, and it
is not that heavy. It is possible that the creation of the app bundle
needs a few steps adding to the 'Copy files' phase at the end, but
this also will be straightforward once you get to it (icons, plist,
other resources?, libraries?). The whole point about a XaraLx-personal
is to weak link to libraries on the current system. not necessarily to
create a 'deliverable'.
I would suggest that we approach this either as using scaffolding to
support people who are wanting to do the build - most importantly by
providing pre-built binaries (such as the wxrc tool) where creating
them de novo is fiddly; or as stepping stones - a series of steps that
only get harder progressively, so that less adept people can use a
'learning curve' technique to get up to speed.
(I will add that my latest build seems to be Tiger only, which I don't
believe is necessary; and I am not quite sure why at this stage. Also,
the unstripped binary seems to be too large to fit onto one CD Rom,
which is a pity).
As always, bugs to Bugzilla so that steps taken to fix them are
recorded, discussions about development here and other things on the
On 13 Jun 2006, at 13:15, Alex Bligh wrote:
>> However, the present objective is to get something simple, working;
>> and if turning off internationalisation helps, then I will do this;
>> but I would recommend that once we have more experience we throw away
>> this work and replace it with something done correctly from the
>> ground up. Not doing internationalisation does
>> not conflict with the functional specification of getting something
>> up and running which will work on the developer's machine so I am
>> not claiming that this is cut and dried.
> All you should need to do is pass an extra flag or two to
>>> How (after all) do you pass in for instance the location
>>> of buildresources.pl itself?
>> With a 'Run Script Build Phase' which is a six line shell script, the
>> last line of which is:
>> Scripts/build-resources.pl --topdir=$SOURCE_ROOT --version="9999"
> You don't need --checksum (md5sum is not used)
> You don't need --xgettext="skip" (unless -i is passed it isn't used)
> You don't need --version="9999" (unless -n is passed for versioning)
> You don't (right now) need --wxrc until you have -i for international
> Can we not assume wxrc etc are on the path, or do (e.g.)
> then set that up the same way you set up $SOURCE_ROOT