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

Re: [XaraXtreme-dev] Re: Success

On 13/06/06, Alex Bligh <alex@xxxxxxxxxxx> wrote:

Ben,

--On 13 June 2006 09:30 +0100 Ben Fowler <ben.the.mole@xxxxxxxxx> wrote:

> There might be some things that could still stand in the way of a
> first-timer, namely,
>
> * The 'build resources' script and the 'wxrc' executable

These should not be problematic. I understand xcode lets you run a
script before you build.


Ooops.

In these threads, I just report what I have done, and respond
(publically) to what others post. I am not claiming that those things
(which may be largely your work) are problems, merely that they are
potential obstables to a first-timer. Without a first-timer for
testing purposes, I can't really say one way or the other.

* The 'Build Resources' script: By eyeball, I think that this will
work without problems. I certainly had to modify it before I could use
it, but I believe that the svn version is OK.

* The 'wxrc' executable: In the same vein, I have a working wxrc,
having build wxWidgets from the command line. I am unsure whether wxrc
is build by our project file, or by following the instructions that we
are proposing to go with that project file. It follows that a
first-timer will need help here, either to create that executable or
to in some way work around his or her's not having it.


I understand Phil has them working. If this /is/ problematic I'd
like to know why as half the reason I converted it to a perl script
(from Makefile voodoo) was so Phil could run it from XCode.


I have these working as well, and should I notice a defect in these
artifacts or their associated methods that needs attention, I will
file a bug report. If there is a problem, you could be the first to
know, and it will go into the proper channels. There is no problem
known to me (but it is perfectly possible that people closer to the
'bare metal' can perceive details better or faster than I, and like
you, I rely on such issues being passed upstream).

(We will need to note that there is now a dependency of a working perl
environment for building Xara LX).

Today's response to Neil is about putting a first-timer in a position
to create a development build of Mac Xara LX for use on his or her
machine and to develop methods so that this becomes a one step
operation: "Download this file; Open it; and Press the 'Build' button"
- the last being the "one step" of which I speak, not necessarily
about documenting and resolving problems in wider areas, and I
apologise if you feel that I am slighting (or misrepresenting) your
work! It might be helpful if, should you consider that I am actually
working on the wrong lines, you could note this, and I will stop and
think.


The wxrc executable is just that - an executable. You can pass a path
to it on the command line for buildresources.pl


I will note that, but if that is the last word on the subject, then we
have created a new obstacle - identifying and possibly pasting in that
path ...


> (The wxXtra files will not compile inside the current project file,
> because they are not compatible with the Xara prefix header: We need
> either to fix the incompatibility - which seems to result from wxXtra
> pulling in old Classic Mac headers - or more reasonably provide a
> wxXtra target which does not use the Xara prefix header (if my
> understanding of the status of wxXtra is correct, then it does not
> need this prefix file)).

wxXtra should not and cannot require the .pch file. wxXtra is entirely
deliberately build as a separate library that does not depend on Camelot,
under the wxWidgets license (as opposed the straight-forward GPL) and
contains wxWidgets code. We should definitely not be integrating into our
own app. Moreover, you may even break things by including the PCH (perhaps
you are saying it does break things). So it  sounds like this is a separate
target.


Last time I looked, late on Saturday, nothing in Xara LX is built as a
separate library: This is way I speak of operations on 590 object
files. (This must be as painful for you as it is for me, and I am
guessing that there is a reason for it).

I am getting outwith today's problem and may be speaking about things
I don't fully understand, but I will agree with you 100%.

o Yes, it does break things
o I have no particular view on the wxWidget licence - Does it really interfere
 with commercial operation or use of the code? If there is an actual
or potential
 incompatibility with the GPL, however, this is most serious!
o wxXtra should be built as separate library
o wxXtra is much more like wxWidgets code than Xara code
o We should consider spinning it off as an entirely separate project, cognate to
 the wxWindows (sic) project file
o At the time of writing, creating a separate project looked the best thing to
 do right now; and I proposed doing this and submitting the patch.

If I am on the wrong lines, you had better tell me, and as I say, I
will  not rush headlong into doing something that will not work


BTW if wxXtra is bringing in old classic Mac headers it's probably
wxgetmousestate that does it. That shouldn't even be compiling anything
if you have wxWidgtets 2.6.3. Separate issue I know...


I think you are right. It is the definition of the 'struct Rect' which
conflicts with Xara's struct Rect. Now, there is a case on general
grounds for putting Xara's struct Rect into a namespace, but even so,
it does look as though wxXtra is pulling in files that it should not,
and it might even be wx's bug.

(There might be another problem, but that is the most obvious one).

My only priority for the next couple of days is identify and
by-passing the obstacles to the goal of providing a project file that
works for a first-timer; it is not about identifying problems, or
worse creating them de novo!

Ben