How to compile Wesnoth on Windows with Dev-Cpp, Code::Blocks

[loonycyborg]

Try using intl.dll from the windows release.

[McShark]

Recent project files, added #define DISABLE_POOL_ALLOC.
You have to do a cleanup/rebuild because of the changed define.

[McShark]

These are the things necessary if we want to remove #define DISABLE_POOL_ALLOC:

Download and unpack pthreads 2.8.0. Copy all files from pthreads-w32-2-8-0-release\Pre-built.2\include to Dev-Cpp\include, \pthreads-w32-2-8-0-release\Pre-built.2\lib\libpthreadGCE2.a to Dev-Cpp\lib and pthreads-w32-2-8-0-release\Pre-built.2\lib\pthreadGCE2.dll to wesnoth-dir.

Now you have to add src\poolaloc.c and src\malloc.c to compiled files, remove the define from the project and add pthreadGCE2 to the list of linked libraries.

Hint: the compiled version without the define does NOT work for me at the moment. I've just posted this here if anybody want's to try using pthreads.

[McShark]

I'll now post updated Codeblock project files for compiling with scons, too. These are always untested (I just add the new files there). These untested files can be found in subdir scons in the attached files.

Edit: Newer versions in SVN

Additional hints for looncyborg:
There are two different targets in scons project file, but they only differ in the file name. Maybe you want to delete the "debug"-target. There are files missing in the .svnignore of projectfiles/CodeBlocks-SCons, there must be the same entries as in projectfiles/CodeBlocks.

[loonycyborg]

There are two different targets in scons project file, but they only differ in the file name.

Their commands have $target placeholder that will be substituted with the name of target by codeblocks causing "build=release" or "build=debug" passed to scons.

[McShark]

OK. I now get the point with the build target.
Can we fit to suffixes for exe-files? I suggest wesnoth_sc.exe and wesnoth_sc-debug.exe, same with wesnothd.
Please write a short summary of the necessary steps to compile with codeblocks via scons when compiling with codeblocks already works. What are the benefits if one uses scons for that tasl?

[loonycyborg]

Can we fit to suffixes for exe-files? I suggest wesnoth_sc.exe and wesnoth_sc-debug.exe, same with wesnothd.

Setting suffixes in the projectfiles will have no effect on name of executable produced by scons, but they must match the binaries scons actually produces in order to be able to run the binary from codeblocks, e.g. from debug menu.

Please write a short summary of the necessary steps to compile with codeblocks via scons when compiling with codeblocks already works.

No additional steps on ubuntu or other linux distros will likely be required. Not tried it on windows.
Running scons from terminal and setting options like boost_suffix and gtkdir will most likely be required on windows, though only once since such options are remembered.

What are the benefits if one uses scons for that task?

SCons can automatically set compile flags(include file search paths etc) on ubuntu and semi-automatically on windows.

[McShark]

Project file update.
@loonycyborg: Please add the file comments as svn comment (if given).

Attachment deleted, newer ones in svn

[ilor]

Why do you want to remove the hpp files from the VC9 project file?

[McShark]

@ilor:

1. removed all .hpp-files because they are included [in the .cpp-files] if needed

2. the other project files does not contain any header files included by .cpp-files
3. I prefer to make the project file as small as possible (only other thing to move is the define of DISABLE_POOL_ALLOC, this belongs to the whole project, not game.cpp and is included in the next necessary update)

What do you think about these points?

[Sapient]

It took me a long time to finally get boost configured correctly, so I thought I would share this:

Code: Select all

bjam -a -q -d+2 "-sZLIB_BINARY=zlib" "-sZLIB_INCLUDE=C:\projects\wesnoth\include\zlib" "-sZLIB_SOURCE=C:\projects\wesnoth\include\zlib" "-sZLIB_LIBPATH=C:\projects\wesnoth\lib" --toolset=gcc --with-iostreams --with-regex

Also, if you want it to find the right "g++" compiler, you have to make sure it is in your %PATH%, since the path to the compiler cannot be configured with "-s" flags. To set path environment variable, right click on My Computer and go to advanced tab. Also, you must close any open command prompt windows, then reopen them before the change to PATH will take effect.

You can find more details about the -sZLIB options and what they mean here: http://www.boost.org/doc/libs/1_37_0/li ... .html#bjam

[governor]

Its funny, I spend hours and hours trying to build iostreams with zlib and bzip support today and had zero success. Currently I'm stuck on building zlib from source, which doesn't seem to be possible from Code::Blocks if I import the .dsp provided. This after struggling forever to first find out that I had to update mingw to build the latest boost under windows - g++ would complain about not finding cc1plus. Bah maybe Ill try again tomorrow.

[Sapient]

Its funny, I spend hours and hours trying to build iostreams with zlib and bzip support today and had zero success. Currently I'm stuck on building zlib from source, which doesn't seem to be possible from Code::Blocks if I import the .dsp provided. This after struggling forever to first find out that I had to update mingw to build the latest boost under windows - g++ would complain about not finding cc1plus. Bah maybe Ill try again tomorrow.

you can import the .dsw, you just have to remove the silly windows resource file (zlib1.rc) from the project.

as far as boost version, I'm still using boost_1_34_1

[ilor]

@ilor:

1. removed all .hpp-files because they are included [in the .cpp-files] if needed

2. the other project files does not contain any header files included by .cpp-files
3. I prefer to make the project file as small as possible (only other thing to move is the define of DISABLE_POOL_ALLOC, this belongs to the whole project, not game.cpp and is included in the next necessary update)

What do you think about these points?

As to 1, I'm entirely unconvinced. Boost headers are also "included in the cpp files" but they are not part of the solution because they are not, logically, Wesnoth code. The hpp files, on the other hand, *are* Wesnoth estate and as such, should be in the solution in my opinion. Also, removing the headers effctively breaks "find text in the solution", which is a useful feature even if you have grep -R handy, just because it's within the IDE.

I won't really comment on the other IDE's projectfiles. IIRC some of them have a swap header/source feature that helps a bit, but that doesn't make a difference in the few header-only bits. Keeping the project file small by hiding accesss to files is imo a very silly goal for a project with several hundred source files and a few megabytes of source code. MSVC has/can have the header files in a separate "filter" so the don't really take up much screen space if you don't wan't to see them all.

Also, I guess having only the cpp files is fine if you only want to build the project. When I'm actually trying to work on the code, I find I'm more productive if the header files are readily available in the project already and I don't have to hunt for them.

Re: the POOL_ALLOC define, there are two reasons for the current behavior:
1. only main.cpp has anything to do with the pool_alloc
2. having the define project-wide *and changing it* will trigger a full rebuild just for the sake of it. Not very encouraging if you just want to try the pool alloc and you know you're probably going to want to go back to the normal alloc later.

[McShark]

Re: the POOL_ALLOC define, there are two reasons for the current behavior:
1. only main.cpp has anything to do with the pool_alloc
2. having the define project-wide *and changing it* will trigger a full rebuild just for the sake of it. Not very encouraging if you just want to try the pool alloc and you know you're probably going to want to go back to the normal alloc later.

Fully convinced about this, I will change this, if possible in all project files. I'll add the define in game.cpp and remove it elsewhere (previously it was global for debug).
Maybe we should do the same with _CRT_SECURE_NO_WARNINGS;HAVE_PYTHON;NO_HAVE_FRIBIDI?

Should we include a kind of README for developers where the DEFINES are set and can be changed?

About the header files: the search and develop argument is good but other IDEs have swapping and with every IDE you can double / right click the include and open the header file this way.
But maybe you're right and we should include them. If we do this, it should be the same in all project files. What do you others think about this?

What do you think about compiling wesnoth using FRIDIBI in all project files?