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

Re: [XaraXtreme-dev] setup.h and configuring wxWidgets (was Re: BLUECAR.xar)

Ben,


* OR use an X-Code and an X-Code project. The X-Code project is
   [not] build by bakefile at the moment, though some people had a go
   at doing this, but never finished it. So it gets out of
   date occasionally (especially on 2.7) but should work on 2.6.
   You will however have to edit setup.h manually.


1. Do you want us to be using wxWidget-2.7 or wxWidgets-CVS? Whilst
there are certainly some advantages to getting bugs out of one's
important libraries, it is nearly always essential in a multi-person
project to stay a little way back from the 'bleeding edge'. In fact,
if I could, I would try to build against wxWidgets 2.5


Hang on, confusion here. wxWidgets maintains two release series,
both called 2.x. Where x is even, that's a stable series (2.6
being the latest one). Where x is odd, it's an unstable development
series (2.7 being the latest one). Whether you get a CVS copy
of either, or a point copy (latest being 2.6.3 and 2.7.0) is
an orthogonal question.

I would recommend using 2.6.3 (the latest stable version) if it
works, else (which is what we do for the static build) use
a recent WX_2_6_BRANCH from cvs (i.e. the 2.6 series latest
development). I am hoping we don't need to use 2.7; on Linux
I've got Camelot to compile against 2.7 and it runs, but is
not extensively tested.

I see no point at all in looking at 2.5, because that was the
previous unstable development series before 2.6 and is now
deprecated.


3. I do think that eventually we need to push this technique as it may
be essential for the 'one step build', but it is  more important that
we follow Christian's lead in this.


I am not sure we ever need get to the "one step build" that
includes building wxWidgets. We aren't there on Linux, and
no-one has suggested we need to be there. wxWidgets is a library
like any other - we don't include libpng, libxml etc. in our
"one step build". Perhaps I'm not understanding where you
are trying to get to here.


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.

Equally, just because wxWidgets is built one way, it doesn't mean
Camelot has to be built the same way.


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. What I am saying is that just because
people want to use XCode to develop Camelot, that doesn't mean they
necessarily have to build wxWidgets using XCode - it seems easier
for them not to, unless they want a wxWidgets UB, which is only
necessary if they want a Camelot UB.

Of course for those developers who chose not to use XCode to
develop Camelot, there is no point using XCode for wxWidgets
at all, because in order to produce a UB they are going to have
to strike up an acquaintance with lipo anyway.

Fortunately, this is now largely an argument about how we right
the build instructions, rather than anything substantive. It
looks like Cristian has working XCode project, and other people
have got to the same place using ./configure and make at
the command line. Which leaves the minor issue of fixing the
code so it works :-)

Alex