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

[governor]

Just a quick update, after pulling out my hairs I finally decided to try some variations of the command line and finally I found my problem: I incorrectly? added the following params to my bjam (as per http://www.boost.org/doc/libs/1_37_0/li ... index.html):

-sNO_ZLIB=0
-sNO_BZIP2=0

Instead of telling bjam to include these options, bjam did the opposite and excluded the libraries from the build.

Just for the sake of completeness here was my final command line, where I separately built zlib and bzip2:

Code: Select all

bjam.exe -a -q -d+2 -sBZIP2_BINARY=libbz2 -sBZIP2_INCLUDE="C:\boost\bzip2-1.0.5" -sBZIP2_LIBPATH="C:\boost\bzip2-1.0.5" -sZLIB_BINARY=zlib1 -sZLIB_INCLUDE="C:\boost\zlib123" -sZLIB_LIBPATH="C:\boost\zlib123\projects\visualc6\Win32_DLL_Release" --build-dir=c:\boost\buildt2 --toolset=gcc --with-iostreams --with-regex

[Max]

any idea why in the last commit this has been done?

VC9: removed all .hpp-files because they are included if needed.

that's quite annoying when searching stuff...

[ilor]

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?

Python is probably, one way or another, going to influence more and more code, and so I guess a project-wide define is better. Don't know about FRIBIDI, if it's more than one file then probably project-wide is better too (thogh iirc I build without it and having it in one file would help me try to get it to work). I wouldn't mind building with fribidi, I just found it was quicker to disable it than to find or build a msvc binary

I guess I'll re-add the header files to VC9. Won't be doing anything to the other project files since I don't use them, and I recall someone didn't want headers in the dev-cpp project.

Max2008: as you can see in the five posts above yours we're discussing the issue and the headers should be coming back soon.

[McShark]

1. I made the files without .hpp, so I'll add them again. I will add them to VC and Code::Blocks (with and without scons). Dev-C++ has no possibility to view header files in a different way/folder, so I will not add them there. Are there any votes against these two points?

2. Dev-C++ is not capable of extra Defines for special files, therefore I will not touch it there. Code::Blocks is capable of this (although not so elegant like VisualStudio, you have to change the compiler line like "$compiler $options -DDISABLE_POOL_ALLOC $includes -c $file -o $object") and therefore I will change this. Visual Studio is set as discussed: Both targets with the define for game.cpp.

3. I like add a Debug target to Code::Blocks without optimization and change the output folders .objs-release and .objs-debug. Any votes against this?

4. Dev-C++ and Code::Blocks are compiled with -O3, does anything speaks against changing the optimization flags from Visual Studio to /Ox (now they are on /O2)?

5. Should we keep Dev-C++ at all? Is anybody here using it (and don't want to change to the actively developed Code::Blocks) anymore?

6. Can somebody add the following lines to game.cpp, please? (I prefer directly before #include "wesconfig.h")

Code: Select all

#ifndef DISABLE_POOL_ALLOC
#include "malloc.c"
#include "poolalloc.c"
#endif

Greetings, McShark

[ilor]

6. Can somebody add the following lines to game.cpp, please? (I prefer directly before #include "wesconfig.h")

Code: Select all

#ifndef DISABLE_POOL_ALLOC
#include "malloc.c"
#include "poolalloc.c"
#endif

I don't think so. Including cpp (i.e. non-header) files is generally a bad idea, and here it's even a C file.

[Iris]

Yeah; you'd have to wrap it up in extern "C" {}. Still, it would be an ugly and evil workaround.

A good workaround would be designing the project so that those files are not included in the compilation and linking steps when the symbol is defined, however. Or wrapping the whole files' contents in a big #ifndef <symbol> (evil, but less evil anyway).

[McShark]

A good workaround would be designing the project so that those files are not included in the compilation and linking steps when the symbol is defined

Isn't this the solution I gave?

[Iris]

Code: Select all

#ifndef DISABLE_POOL_ALLOC
#include "malloc.c"
#include "poolalloc.c"
#endif

This is the problem I was speaking about; you didn't mention anything about excluding the *files* from compilation except this evil workaround.

Dev-C++ is not capable of extra Defines for special files, therefore I will not touch it there.

Better would be to wrap the files themselves in the #ifndef above. Just don't try to convince us to do such a thing in game.cpp itself.

[McShark]

Put the whole files into #ifndef? If you and the other devs think this really would be better then submit this. If you do this, then maybe this should be done also for HAVE_PYTHON and DISABLE_EDITOR2

Code: Select all

 game.cpp, lines 77 to 83 from trunk, lines 85 to 88 were added in my local copy:

#ifdef HAVE_PYTHON
#include "ai_python.hpp"
#endif

#ifndef DISABLE_EDITOR2
#include "editor2/editor_main.hpp"
#endif

#ifndef DISABLE_POOL_ALLOC
#include "malloc.c"
#include "poolalloc.c"
#endif

[ilor]

there's a difference between conditionally including a *header* and pasting one source file into another. Specifically, the latter is not a good solution.

[McShark]

OK, you're right. Is it a better solution to put two whole source files into a #ifndef? If yes: Please commit this to svn, so that there is a solution in svn.

If we can agree to this solution I will move the define for Code::Blocks / VC9 to these two files (malloc.c and poolalloc.c).

[McShark]

Would somebody please edit .svnignore from projectfiles/CodeBlocks from .objs to .objs*?
Would somebody please wrap the files "malloc.c" and "poolalloc.c" in the #ifndef DISABLE_POOL_ALLOC as Shadow Master suggested?

I've wanted to post newer project files here but these two things should be solved first.

Thank you.

[loonycyborg]

Done.

[McShark]

Fine, thank you. Here are the newer project files.
For VC9 and Code::Blocks, project files with the used game headers will follow in the next 1-2 weeks.

[McShark]

Changed the attachment from the previous post to recent files.

Again: If it's possible it would be good to add the following entries to /trunk/.svnignore
manual_html (comes with Wesnoth for windows installation)
Release (Useful for eclipse-projectfiles, Debug exists there already)