[Box Backup] Compile Boxi from tarball or trunk?

[Achim]

Hello Chris:

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
> now.

OK.

> 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.

OK.

>> * * * 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.

OK.

>> // This setting is for Win32 only and can only be enabled if your
>> compiler
>> // supports Win32 structured exception handling (currently only VC++
>> does)
>> //
>> // 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

>> --with-cppunit-prefix=/usr/local
>
> 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 
command.

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/
>> ./configure-mingw.sh
>>
>> 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
>> /usr/local/include/wx-2.8/wx/msw/chkconf.h
>> # 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
> compiling.
>
>> 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