How do you compile the new branches?

[crux]

looking in your guys repo I saw a branch named warzone2100.svn.sourceforge.net/svnroot/warzone2100/branches/qt.
I can't get it to compile on windows no matter what compiler I have tried.
I have tried both MSVC and mingw and neither work?

what are these about?

warzone2100.svn.sourceforge.net/svnroot/warzone2100/branches/pathfinding
warzone2100.svn.sourceforge.net/svnroot/warzone2100/branches/savegame
warzone2100.svn.sourceforge.net/svnroot/warzone2100/branches/sound
warzone2100.svn.sourceforge.net/svnroot/warzone2100/branches/tagfile

warzone2100.svn.sourceforge.net/svnroot/warzone2100/branches/2.2_net
is there going to be another 2.2 release?

[Per]

Qt branch will be merged with trunk shortly. Ways and instructions to compile will likely be improved along with that.

The savegame branch is my playpen for coming up with a new map and savegame format for the game based on INI and PNG files. I am currently reworking this against trunk, and the branch will likely be deleted soon.

The sound branch is ancient, abandoned and should probably have been deleted a long time ago. The same goes for path-finding (contents have already been merged against trunk), tagfile (an older new map/savegame format effort of mine) and 2.2_net (though I actually have no idea what this is).

[cybersphinx]

2.2_net

was where the trunk netcode was merged into 2.2, which was then branched to 2.3.

[crux]

Qt branch will be merged with trunk shortly. Ways and instructions to compile will likely be improved along with that.

pardon me for sounding dumb, but shouldn't people be able to compile it before the merge?
how else are you guys testing windows builds of this?

The savegame branch is my playpen for coming up with a new map and savegame format for the game based on INI and PNG files. I am currently reworking this against trunk, and the branch will likely be deleted soon.

The sound branch is ancient, abandoned and should probably have been deleted a long time ago. The same goes for path-finding (contents have already been merged against trunk), tagfile (an older new map/savegame format effort of mine) and 2.2_net (though I actually have no idea what this is).

thanks for your answers

[crux]

just for clarification, what I mean is that I read you don't have any windows developers now so how do you know the qt branch will work out?

if you did have windows developers then the windows build system would be working right?

I have looked and read this

Visual Studio (Windows)

We do most of our Windows development on Windows XP, using Microsoft Visual Studio .NET 2005 and Visual Studio 2008 (both the 32- and 64-bit versions).

Qt works with the Standard Edition, the Professional Edition and Team System Edition of Visual Studio 2005.

We also test Qt 4 on Windows XP with Visual Studio .NET and Visual Studio 2003.

In order to use Qt with the Visual Studio 2005/2008 Express Edition you need to download and install the platform SDK. Due to limitations in the Express Edition it is not possible for us to install the Qt Visual Studio Integration. You will need to use our command line tools to build Qt applications with this edition.

The Visual C++ Linker doesn't understand filenames with spaces (as in C:\Program files\Qt\) so you will have to move it to another place, or explicitly set the path yourself; for example:

QTDIR=C:\Progra~1\Qt

If you are experiencing strange problems with using special flags that modify the alignment of structure and union members (such as /Zp2) then you will need to recompile Qt with the flags set for the application as well.

If you're using Visual Studio .NET (2002) Standard Edition, you should be using the Qt binary package provided, and not the source package. As the Standard Edition does not optimize compiled code, your compiled version of Qt would perform suboptimally with respect to speed.

With Visual Studio 2005 Service Pack 1 a bug was introduced which causes Qt not to compile, this has been fixed with a hotfix available from Microsoft. See this Knowledge Base entry for more information.

and

GCC on Windows (MinGW)

We have tested Qt with this compiler on Windows XP. The minimal version of MinGW supported is:

* GCC 3.4.2
* MinGW runtime 3.7
* win32api 3.2
* binutils 2.15.91
* mingw32-make 3.80.0-3

Note: For users of the MinGW binary package: This package is now based on MinGW 4.4. The installer no longer offers to download MinGW for you, but rather offers to use a version of MinGW that you already have installed on your machine. You just tell the installer which directory MinGW is installed in. If you don't already have MinGW 4.4 installed, you can download a .zip archive from our ftp site. This archive provides fixes to MinGW and support for missing API, See the _patches directory in the archive for details.

Note: A MinGW installation is only needed to build against the binary pacakge, not to run the pre-compiled binaries that are in the package.
GCC 4.0.0

The released package of the compiler has some bugs that lead to miscompilations. We recommend using GCC 4.0.1 or later, or to use a recent CVS snapshot of the GCC 4.0 branch.

since you guys use a cross-compiler for windows builds I did a quick look at the makefile and that doesn't have any qt references?

[Zarel]

pardon me for sounding dumb, but shouldn't people be able to compile it before the merge?
how else are you guys testing windows builds of this?

When Per says that Qt branch will be merged shortly, he means after we have figured out how to successfully compile it for Windows and Mac OS X. We currently cannot do so, either on Windows or OS X, which makes it impossible for me to work on it.

just for clarification, what I mean is that I read you don't have any windows developers now so how do you know the qt branch will work out?

Well, Buginator is back, and he uses Windows for development. He uses MSVC, and I use MinGW, so we maintain a minimal level of compatibility by using that.

After all, we said that a month ago, we didn't have any developers who use Windows as a primary development platform. We still have access to Windows.

since you guys use a cross-compiler for windows builds I did a quick look at the makefile and that doesn't have any qt references?

As mentioned above, we haven't created one yet, but we will be sure to make a Windows-compatible makefile before merging it into trunk.

[crux]

pardon me for sounding dumb, but shouldn't people be able to compile it before the merge?
how else are you guys testing windows builds of this?

When Per says that Qt branch will be merged shortly, he means after we have figured out how to successfully compile it for Windows and Mac OS X. We currently cannot do so, either on Windows or OS X, which makes it impossible for me to work on it.

thanks for the clarification.
I was a bit worried.

[crux]

what is the major drive or factors for using Qt anyway?
was there something wrong with simple directmedia layer?

[Zarel]

what is the major drive or factors for using Qt anyway?
was there something wrong with simple directmedia layer?

Several things. One of my least favorite things about SDL is that it's impossible to have colored hardware-accelerated cursors - you can either have black-and-white cursors, or laggy colored cursors (60fps may be enough for the game, but it's not enough for a cursor...).

Qt also eliminates the need for QuesoGLC, which has been causing us a few font-related problems.

Qt also allows for easier integration with the operating system, enabling features such as double-clicking on a map or mod to install it, etc, without having to use an external launcher.

Qt reportedly also improves performance, which may be caused by that it eliminates the need for a lot of somewhat-problematic dependencies other than just SDL.

[Crymson]

Several things. One of my least favorite things about SDL is that it's impossible to have colored hardware-accelerated cursors - you can either have black-and-white cursors, or laggy colored cursors (60fps may be enough for the game, but it's not enough for a cursor...).

Qt also eliminates the need for QuesoGLC, which has been causing us a few font-related problems.

Qt also allows for easier integration with the operating system, enabling features such as double-clicking on a map or mod to install it, etc, without having to use an external launcher.

Qt reportedly also improves performance, which may be caused by that it eliminates the need for a lot of somewhat-problematic dependencies other than just SDL.

What about all the things wrong with the qt branch?

Yikes! http://developer.wz2100.net/ticket/1549

I sure hope you guys don't switch anytime soon!

[Zarel]

What about all the things wrong with the qt branch?

Yikes! http://developer.wz2100.net/ticket/1549

I sure hope you guys don't switch anytime soon!

Well, we'd obviously fix all those issues before switching over. There's really no need to worry.

[EvgenijM86]

Is there a TODO list for Qt branch (other than that ticket)?

[Per]

That ticket is the TODO list. I am sure it could be expanded upon.

Of course, anything that doesn't work but that does work in trunk, should be fixed, and patches are most welcome.

[BunkerBlaster]

Was thinking about making new Dev packages for MSVC2008, MSVC2010 and MinGW. Just wondering if the Qt branch is going to break MSVC express and or MinGW?

[Buginator]

Was thinking about making new Dev packages for MSVC2008, MSVC2010 and MinGW. Just wondering if the Qt branch is going to break MSVC express and or MinGW?

For what it is worth, Qt will make it so MSVC builds are 100% static. (Assuming you compile Qt to be static).
As for new dev packages, those will eventually be made, just pressed for time , and got other things to fix first. Any help in that area would be nice.

Oh, as for 2k10, not sure about that right now. I am still sticking with 2k5 for now...