FreeOrion

Have you guys checked out Autopackage which could be a great way of supporting most distros with minimum effort.

Yoghurt wrote:

Wolverine wrote:Ok. Now I understand. However I still think that I have seen somewhere in the documentation that autopackage takes care of such things.

Yes, but they also mention it doesn't really work for C++ projects.

I see... Oh well. If you want I can prepare Mandriva 2005LE rpm's as soon as the CVS is stable.

Yoghurt wrote:

However the latest CVS is broken as hell.

Then please, please, submit bug reports ASAP, as the CVS currently is identical with the upcoming 0.3 release

Posted. I found three new bugs as of now.

Also. Could you please make "clean" target for Scons?

Wolverine wrote:Could you please make "clean" target for Scons?

There is a "--clean" option built-in.

Thanks for the info.

You need .deb and different kinds of .rpm. Oh. Wesnoth has all of them.

Anyway how binaries from Lokigames work on all linux distros?

Lokigames existed in a time where there was only one version of ABI in use, not 2 like it is now.

As suggested earlier in the thread, you should just use autopackage and let the distros worry about providing their own specific packages if they really want to.

And as already stated earlier, I had prepared an autopackage based binary. And that wouldnt work on most distros.

Yoghurt wrote:And as already stated earlier, I had prepared an autopackage based binary. And that wouldnt work on most distros.

Did you tell the autopackage guys about this? I'm sure they'd be either able to fix it to work on most distros or be eager to address any shortcomings you have exposed with their system.

autopackage homepage wrote:Important note to C++ developers

If your software uses QT/kdelibs, or just relies on large C++ libraries, then you must be careful. [...] Because of this, we cannot guarantee that your software will run on all systems. [...]Full C++ support is planned for autopackage 1.2. Our solution is to double compile C++ applications and select the correct binary at install time.

I might go with the double-compile approach, but for now I have to get FO to work on my own machine (it crashes mysteriously since a while ago)

Yoghurt wrote:

autopackage homepage wrote:Important note to C++ developers

If your software uses QT/kdelibs, or just relies on large C++ libraries, then you must be careful. [...] Because of this, we cannot guarantee that your software will run on all systems. [...]Full C++ support is planned for autopackage 1.2. Our solution is to double compile C++ applications and select the correct binary at install time.

I might go with the double-compile approach, but for now I have to get FO to work on my own machine (it crashes mysteriously since a while ago)

Yeah, when splitting fleet for example. :-(

quork wrote:Yeah, when splitting fleet for example.

Are you using the v0.2 download? That had known fleet splitting bugs.

If it's happening (again) in v0.3 from CVS, then please post a bug report ASAP.

Geoff the Medio wrote:

quork wrote:Yeah, when splitting fleet for example. :-(

Are you using the v0.2 download? That had known fleet splitting bugs.

If it's happening (again) in v0.3 from CVS, then please post a bug report ASAP.

I'm using tainted source files from current CVS (20051203 11:28 GMT). GiGi doesn't install headers where it's expected (/usr/local/include/GG), so I had to copy them manually (I'm debianizing libgigi and FreeOrion builds). scons install only creates /usr/local/include/GG and copies only one header file.

I also suspect that libgigi isn't updated with developer's versions, because FreeOrion refuses to compile with errors such:

} catch (const FileDlg::InitialDirectoryDoesNotExistException& e) {
UI/OptionsWnd.cpp:964: error: syntax error before `&' token

same with InGameOptions.cpp

This exception is not defined in dialogs/GGFileDlg.h where it IMO should be. It defines BadInitialDirectory exception instead.

The other one is with GG::ListBox::DontAcceptDropException(); in UI/FleetWindow.cpp that emits message about unknown class member ListBox::DontAcceptDropException (maybe it should be called as DontAcceptDrop only? I don't know, I'm not C++ developer.)

I'm using debian-testing with gcc 3.3.6.

Are you using the current CVS GG? Based on what tzlaine told me, I'd suggest getting the 0.6.0 version of GG from the GG site, instead. That might fix some of the compilation problems FO is having... CVS FO with 0.6.0 GG compiles and runs fine for me... (though I'm on WinXP)