[Box Backup] Compile Boxi from tarball or trunk?
Fri, 03 Apr 2009 23:59:00 +0200
On 2/4/09 19:48, Chris Wilson wrote:
> Did you start with a completely clean wx source after changing
> setup.h.in? This file is converted into something else, quite early in
> the build process.
Yep, downloaded the tar ball and started with a fresh copy.
> Ok, I don't particularly care about compiling 2.6 manually, either
> distributions have it or they don't, in which case people should use 2.8
> We have our own library of wx test functions, based on Reinhard
> Fureder's work, which we use to generate simulated wx events in cppunit
> tests, to drive the gui from cppunit tests. The integration of cppunit
> and wx in this way is very hairy and complex, I recommend that you don't
> touch it.
>> * * * Zlib * * *
>> BUGBUG not required?
> What is bugbug and why is it not required? :)
> Zlib is required for boxi because it's required for box backup.
Well, I use the zlib and zlib-devel that is provided by Cygwin for now,
but the standalone library is of course also a valid choice.
>> BUGBUG what about these:
>> #define wxUSE_UNICODE 1
> Don't know if they need changing. Unicode is certainly required.
>> // This setting is for Win32 only and can only be enabled if your
>> // supports Win32 structured exception handling (currently only VC++
>> // Default is 1
>> // Recommended setting: 1 if your compiler supports it.
>> #define wxUSE_ON_FATAL_EXCEPTION 1
> I guess it doesn't work on mingw then, so it should be turned off.
The thing i
> What is this doing in the wx configuration line?
This was just a try to see if the manually compiled CPPunit (as opposed
to the Cygwin package) would work: it does not, as you have seen from
the error messages. The directive is a perfectly valid wx configuration
The errors described in the previous post happen with cygwin CPPunit and
the manually compiled and installed CPPunit (in /usr/local).
>> Download Boxi from SVN (also fetches latest boxbackup from svn)
>> svn co https://svn.sourceforge.net/svnroot/boxi/trunk/boxi
>> cd boxi/
>> Will not result in a working Makefile for box, so we need to do that
>> manually and downgrade to compilabe R2465 at the same time:
> I've seen this problem as well, but I don't think it's the correct
> solution. Instead, just remove the line from configure.in that moves
> Makefile to Makefile.in.
OK. I see that this has been updated in Trunk R627: Thanks!
>> * * * wxStackFrame and wxStackWalker * * *
>> wxStackFrame and wxStackWalker are not available even after the
>> changes in
>> setup.h.in and the corresponding MSW file.
>> change following lines (around 82) in
>> # define wxUSE_ON_FATAL_EXCEPTION 1
>> # define wxUSE_CRASHREPORT 1
>> # define wxUSE_STACKWALKER 1
> You can't just change that file, it will result in link errors as you
> saw. You have to get wx to use and install the correct version when
>> Does this perhaps von MSVC++? From the file:
> Yes, some of these don't work with mingw.
Perhaps I am missing something here: You are saying that Boxi is
compilable with Cygwin native (MinGW). At the same time, Boxi relies on
wxStackwalker, which in turn only becomes available when compiling a wx
application with MSVC++ (as per the above comments in chkconf.h).
It appears to me that Boxi in fact mandates the use of MSVC++, in order
to be able to use wxStackwalker.
Would it perhaps be possible to remove this dependency on non-free
software by making the use of wxStackwalker configurable?
I will try again now with R629.
Best regards, Achim