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

[Mist]

Fribidi only provides right-to-left support, you don't have to compile with it if you don't require that (in that case just remove -DHAVE_FRIBIDI flag from project compiler options)

But otherwise, it's nearly impossible to get a hold of win32 build of fribidi on the net. I posted one here few weeks ago, but it got lost in the crash, if you wait till tommorow I'll repost it again.

[McShark]

Try to rename the attachement

libfribidi.txt

(5.04 KiB) Downloaded 545 times

to .a , put this to your folder dev-cpp\lib and try to compile again (no need to rebuild)

[loonycyborg]

Anyway, fribidi dependency will be dropped when wesnoth finishes moving to pango since it handles left-to-right support itself and has a version of fribidi in its source tree.

[BroodKiller]

Thanks guys, I just wanted to report a success, although I had to rebuild without fribidi and handle some dll problems along the way. It is indeed a joyful day

[McShark]

Anyway, fribidi dependency will be dropped when wesnoth finishes moving to pango since it handles left-to-right support itself and has a version of fribidi in its source tree.

Sounds good, as SDL is dropped, too, when wesnoth finishes moving to pango. Let me guess: After having done that the first wesnoth 1.5 stable is released, right?

@Mist: Why did you change "-march=native" to "-march=athlon"? Shouldn't be -lpango-1.0, -lpangocairo-1.0 and -lgobject-2.0 be named as they are originally? The dll's in wesnoth 1.4 stable are named the same way, I think it's better to make this in that way.

[ivanovic]

Sounds good, as SDL is dropped, too, when wesnoth finishes moving to pango. Let me guess: After having done that the first wesnoth 1.5 stable is released, right?[/quote]

Uhm, several things about this:

* No, why should we drop sdl? maybe we will drop sdl-ttf, but not sdl itself.
* There are by definition no "1.5 stable releases" (as there are no 1.5 beta releases). That is 1.5 is the development branch and will eventually become the new stable series which is likely to be named 1.6.x.

[loonycyborg]

Sounds good, as SDL is dropped, too, when wesnoth finishes moving to pango. Let me guess: After having done that the first wesnoth 1.5 stable is released, right?

Both SDL_ttf(not SDL and other SDL_* libs) and fribidi deps will be dropped in 1.6 unless some nasty bug prevents pango integration from succeeding.

[McShark]

SDL_ttf was exactly what I've meant. Now I've understand the version numbers for bow, good to know, too.
Mist: What about the project file (naming of pango libs)?

[McShark]

Here are the new dev-files (Hurray, .dev is an allowed attachement type now).

Edit: Removed, newer versions in SVN

[BroodKiller]

I just want to report that I have tested it and the abovementioned Dev-Cpp method is compatible also with CodeBlocks 8.02. I used a Dev-C++ project file and it imported fine (CodeBlocks supports it) but had to manually set the proper compiler "include" and linker "lib" paths, that pointed to items extracted from the DevCpp packages mentioned earlier. The compiler showed some warnings, but nothing of big importance. An important issue is that the MinGW version that comes with CodeBlocks gave me some issues on linking: it didn't like some of the libs (e.g. the 2 boost libs: regex and iostream) that I had compiled earlier. My guess is that it had to do with the magic -dw2 thing, but I am not sure. Using the MinGW version package mentioned earlier in this thread (and setting the proper compiler paths, if needed) solved the problem.

EDIT:
The easy way for CodeBlocks (but the lib package should work for Dev-Cpp as well)

1)Download a SVN checkout of the Wesnoth sources and put it somewhere.
http://www.wesnoth.org/wiki/WesnothSVN

2)Download CodeBlocks 8.02 without MinGW from here:
http://www.codeblocks.org/downloads/binaries

Install it anywhere you want ("C:\Program Files\CodeBlocks" by default). Don't use the MinGW that comes bundled with CodeBlocks because it won't link properly (at least with the lib package used here).

3)Download the prepared lib package (about 27 MB). Extract the files from the "IDE_files" directory to your CodeBlocks installation directory. Extract the files from the "Wesnoth_libs" directory to where you have downloaded the Wesnoth source.
http://www.mediafire.com/download.php?nvxojac1czg
http://fourierdreams.com.ar/downloads/weswin.rar [mirror courtesy of talosds ]

This is basically just an updated version of the McShark's Dev-Cpp pack.

4)Run CodeBlocks, and go to Settings->"Compiler and Debugger"->"Global compiler settings". Make sure the "Selected Compiler" is the GNU GCC Compiler and go to the "Toolchain executables" tab.

If it isn't already, change the "Compiler's installation directory" to your CodeBlocks installation directory (and NOT its "/bin" subdir for example). Also change the names of the C compiler (gcc), C++ compiler (g++) and the Linker for dynamic libs (g++) by adding a "-dw2" at the end. You should have "mingw32-gcc-dw2.exe" and "mingw32-g++-dw2.exe".

5)Go to the "Search directories" tab and add "Your-Codeblocks-path\include" to the Compiler ("C:\Program Files\CodeBlocks\include" by default) and "Your-Codeblocks-path\lib" to Linker ("C:\Program Files\CodeBlocks\lib" by default).

6)Download and rename to *.cbp the attached CodeBlocks project file OR import an existing Dev-Cpp project file. In the latter case you'll probably need to manually include some extra files and remove the -HAVE_FRIBIDI compiler define.

The above method works with the trunk from 22.08.2008, but things might change in the future. It is recommend to use newer versions of these packs if available. For this, you have to make the appropriate steps of the original Mist's guide.

If there are any problems with this method please let me know, I may have missed something along the way.

[BroodKiller]

If someone would be so kind as to host the lib package from above, I would be very grateful, because mediafire deletes the hosted files after some time. Of course I will reupload, but still someone may want to get it in the meantime. Kind thanks!

[talosds]

Just followed the instructions with CodeBlocks and it works perfectly, 99,9% out of the box! I just had to copy the language_win32.ii which wasn't inside the source tarball (I'm using version 1.5.3) from the SVN repository, but that's all. Thanks a lot, BroodKiller!!!

Btw, here's a little contribution. I'm hosting the weswin.rar file here, and it'll be there for as long as you folks want: http://fourierdreams.com.ar/downloads/weswin.rar

[ivanovic]

Hehe, the reason that you had to copy it yourself is that we (so far) had no detection for those .i and .ii template files in our packaging software. That is: the one adding the file would have had to add it to Makefile.am to have it known as part of the package process. This was not done and since it is not needed on Linux where I test the tarball, I did not spot this missing file and as such it was not in the tarball...

This should not happen anymore for 1.5.4+.

[Tillanz]

Thanks for the guide BK! I compiled basically as described in BK's post. After downloading language_win32.ii it compiles with warnings:

Compiling: src\game.cpp
In file included from C:\Dev\CodeBlocks\include/Python.h:92,
from C:\Dev\wesnoth-1.5.3\src\/ai_python.hpp:23,
from C:\Dev\wesnoth-1.5.3\src\game.cpp:72:
C:\Dev\CodeBlocks\include/stringobject.h:64: warning: 'libintl_printf' is an unrecognized format function type
C:\Dev\CodeBlocks\include/stringobject.h:66: warning: 'libintl_printf' is an unrecognized format function type
In file included from C:\Dev\CodeBlocks\include/Python.h:114,
from C:\Dev\wesnoth-1.5.3\src\/ai_python.hpp:23,
from C:\Dev\wesnoth-1.5.3\src\game.cpp:72:
C:\Dev\CodeBlocks\include/pyerrors.h:193: warning: 'libintl_printf' is an unrecognized format function type
C:\Dev\CodeBlocks\include/pyerrors.h:327: warning: 'libintl_printf' is an unrecognized format function type
C:\Dev\CodeBlocks\include/pyerrors.h:329: warning: 'libintl_printf' is an unrecognized format function type
In file included from C:\Dev\CodeBlocks\include/Python.h:122,
from C:\Dev\wesnoth-1.5.3\src\/ai_python.hpp:23,
from C:\Dev\wesnoth-1.5.3\src\game.cpp:72:
C:\Dev\CodeBlocks\include/sysmodule.h:17: warning: 'libintl_printf' is an unrecognized format function type
C:\Dev\CodeBlocks\include/sysmodule.h:19: warning: 'libintl_printf' is an unrecognized format function type

Attempting to run produces the error:
"The procedure entry point libintl_snprintf could not be located in the dynamic link library intl.dll"

[talosds]

The same happened to me. I just ignored the warnings, and then replaced both intl.dll and iconv.dll with the same files from the lastest gimp package for Windows. Everything ran well after doing so.

And to Ivanovic, thanks for the explanation! I guessed there must've been some reason for the file not being included within the package, but I was certainly clueless. Just thought it'd be worth mentioning for those trying to compile the sources the same way I did.