On Beta Testing

[iceiceice]

Hmm well it sounds like might be some kind of problem with the installation?

From the scons changelog:
- Avoid an infinite loop on non-Windows systems trying to find the
SCons library directory if the Python library directory does not
begin with the string "python".


On my machine, when I type scons outside of the project directory, I get the following:

Code: Select all

$ scons

scons: *** No SConstruct file found.
File "/usr/lib/scons/SCons/Script/Main.py", line 905, in _main

I guess we might have some kind of platform-specific bug in our SConstruct file? I'm just guessing though.

Edit:

The scons script is pretty actively maintained, and I guess is actually used by the Code::Blocks-Scons variant (that other project file in the repo that I keep updating)? Here was a recent PR:
https://github.com/wesnoth/wesnoth/pull/184

If you really think it's broken and you can't fix it I would suggest to make a bug report.

Edit:

Seriously, I think it's fair to say that scons is the best supported way to build wesnoth right now, if it doesn't work we want to know.

Scons is what is used on travis, also on the daily jenkins build, which also builds a windows executable: http://baldras.wesnoth.org:8080/me/my-v ... onsoleText

Edit:

Possibly helpful / relevant:
http://www.scons.org/wiki/SConsAndCygwin

[Pentarctagon]

Well, I am using windows 7, so that shouldn't apply.

Also rather interesting is that when run normally (from a bat file) it does the infinite loop thing, but when run as Administrator it says that "scons" isn't a recognized command.

edit - attempting to run the scons.bat or scons-2.3.1.bat that came with the installation gives the SConstruct error you posted:

Code: Select all

scons: *** No SConstruct file found.
File "C:\Python27\Scripts\..\Lib\site-packages\scons-2.3.1\SCons\Script\Main.py"
, line 916, in _main

[iceiceice]

Based on this,

I think maybe you are supposed to go to the wesnoth directory and type C:\Python...\Scripts\scons ?

the SCons Batch files (*.bat, no Exes!) get installed to the "Scripts" folder of your local Python
installation, e.g. "C:\Python26\Scripts".
Call them either with the full path each time, or add it to the PATH environment variable.

Best regards,

Dirk

[Pentarctagon]

Well, for some reason that worked even though I had added the directory to the PATH. Though now it fails since I'm apparently missing a lot of pre-requisites:

Code: Select all

S:\Battle_for_Wesnoth_1.13>C:\Python27\Scripts\scons
scons: Reading SConscript files ...
Building Wesnoth version 1.13.0-dev
Mkdir("build")
---[checking prerequisites]---
Checking for C library m... yes
Checking for C function round()... yes
Checking for Simple DirectMedia Layer library version >= 1.2.0... 'pkg-config' i
s not recognized as an internal or external command,
operable program or batch file.
'sdl-config' is not recognized as an internal or external command,
operable program or batch file.
no
Checking for SDL_ttf library version >= 2.0.8... no
WARN: Base prerequisites are not met
WARN: Client prerequisites are not met. wesnoth, cutter and exploder cannot be b
uilt
WARN: Unit tests are disabled because their prerequisites are not met
  If any config checks fail, look in build/config.log for details
  If a check fails spuriously due to caching, use --config=force to force its re
run
NLS tools are not present...
NLS catalogue installation is disabled.
---[applying configuration]---
'utils' is not recognized as an internal or external command,
operable program or batch file.
scons: done reading SConscript files.
scons: Building targets ...
error_action(["wesnoth"], [])
scons: *** [wesnoth] Target disabled because its prerequisites are not met
scons: building terminated because of errors.
Press any key to continue . . .

[loonycyborg]

I'm making windows releases using scons, here's my .scons-option-cache:

Code: Select all

default_targets = 'test,wesnoth,wesnothd'
sdldir = 'K:\\sergey\\wesnoth-deps\\'
boostdir = 'D:\\boost_1_46_1\\'
boostlibdir = 'D:\\boost_1_46_1\\stage\\lib\\'
boost_suffix = '-mgw45-mt-1_46_1'
gettextdir = 'K:\\sergey\\wesnoth-deps\\'
gtkdir = 'K:\\sergey\\wesnoth-deps\\'
openmp = True

So as you can see, openmp is used in 'official' releases.
I've uploaded contents of wesnoth-deps dir to sourceforge, but it doesn't have boost because binary boost builds are likely to end up incompatible with installed mingw-gcc.
http://sourceforge.net/projects/wesnoth ... p/download
So if you want to make scons work, put the above settings into .scons-option-cache file at the checkout and adjust it according to your actual lib files.

[Pentarctagon]

Well, I'm compiling boost as we speak, so hopefully that ends well...

But on that note, as a warning to other people: DO NOT try to interrupt/stop it from building anything. Bad things may happen.

edit - Finished compiling and fixing the .scons-option-cache file:

Code: Select all

default_targets = 'test,wesnoth,wesnothd'
sdldir = 'S:/Battle_for_Wesnoth_1.13/dependencies/'
boostdir = 'E:/All_Junk/boost/compiled_boost_1_46_1/'
boostlibdir = 'E:/All_Junk/boost/compiled_boost_1_46_1/lib/'
boost_suffix = '-mgw45-mt-1_46_0/'
gettextdir = 'S:/Battle_for_Wesnoth_1.13/dependencies/'
gtkdir = 'S:/Battle_for_Wesnoth_1.13/dependencies/'
openmp = True

Though it can't seem to find boost for some reason.

Also made a batch file to compile boost if anyone's interested:

Code: Select all

@echo off
set /p coreCount=Enter the number of cores to use (if you don't know use 1): 
@echo on

cd tools/build/v2/engine/src/
call build.bat mingw

cd ../../../../../
move "%~dp0tools\build\v2\engine\src\bin.ntx86\bjam.exe" %~dp0

call bjam -j %coreCount% --toolset=gcc --build-type=complete stage  "--prefix=../compiled_boost_1_46_1" install

echo "Boost build complete!"
pause

just stick it in the boost directory and run it.

[loonycyborg]

Why is there a slash in boost_suffix? It's not a directory name, but the part of name of the boost library, the one between libboost_whatever and .dll.a
Also, I think it should be boostdir = 'E:/All_Junk/boost/compiled_boost_1_46_1/include'
I don't install boost myself. Use it right from source dir and link against staged libs in stage/lib. Those are made on plain build step, not install.

[Pentarctagon]

Yep, the slash was the problem. No idea why it was there.

Though now that I cleared the "boost version >- 1.34.1" check, it's saying that I'm missing gzip support in Boost Iostreams.

[loonycyborg]

oh. You need to build boost.iostreams with zlib and bzip2 support. Don't remember how exactly do you enable them. Last build of boost I did was cross-compile and it enables those by default.
http://www.boost.org/doc/libs/1_55_0/li ... .html#bjam <- that's boost's own docs on those features.
https://github.com/wesnoth/wesnoth/tree ... tfiles/VC9 <- this README has some information on compiling boost that applies to mingw too. wesnoth-deps contain both bzip2 and zlib.

[Pentarctagon]

I couldn't get it to work with the files in wesnoth-deps, so I downloaded the zlib/bzip2 source from their websites. I got it to compile with bzip2/zlib by adding:

Code: Select all

-s BZIP2_SOURCE=<bzip2 source dir> -s ZLIB_SOURCE=<zlib source dir>

So the bzip2/zlib lib files are there now, however it still says that I don't have them.

[aquileia]

What I used to build boost was simply

Code: Select all

bootstrap
.\b2 -sNO_ZLIB=0 -sZLIB_SOURCE=G:\zlib-1.2.8 -sNO_BZIP2=0 -sBZIP2_SOURCE=G:\bzip2-1.0.6

I have to say though that the toolset (Visual Studio 2013) was auto-recognized in my case.

So could you possibly be missing the

Code: Select all

-sNO_ZLIB=0 -sNO_BZIP2=0

options?

[Pentarctagon]

No change, it's still not detected.

I do get two warnings of:

Code: Select all

warning: unable to construct ./install-unversioned

though I hadn't been able to find anything informative about them and they didn't seem to be causing any issues.

[loonycyborg]

You mean it still fails on gzip support in boost iostreams? Be sure to check that the build process of boost iostreams compiled bzip2.cpp and zlib.cpp. Also, you can look in build/config.log to see what exactly is wrong with gzip /w iostreams test program. If there's no information due to tests being up-to-date re-run scons with --config=force

[Pentarctagon]

It passes gzip support, but fails on bzip2. I've uploaded the build.log from the normal "scons" (build.log) and "scons --config=force" (force-build.log), the results of my make.bat, and the command line output from "scons --config=force".

make.txt does (from what I can tell) show boost-iostream compiling with zlib/bzip2:

Code: Select all

common.mkdir bin.v2\libs\program_options\build\gcc-mingw-4.5.2\release
gcc.compile.c++ bin.v2\libs\math\config\gcc-mingw-4.5.2\release\link-static\threading-multi\has_long_double_support.o
common.mkdir bin.v2\libs\program_options\build\gcc-mingw-4.5.2\release\link-static
common.mkdir bin.v2\libs\random\build\gcc-mingw-4.5.2\release
common.mkdir bin.v2\libs\program_options\build\gcc-mingw-4.5.2\release\link-static\threading-multi
common.mkdir bin.v2\libs\random\build\gcc-mingw-4.5.2\release\link-static
gcc.compile.c++ bin.v2\libs\iostreams\build\gcc-mingw-4.5.2\release\link-static\threading-multi\gzip.o
gcc.compile.c++ bin.v2\libs\iostreams\build\gcc-mingw-4.5.2\release\link-static\threading-multi\zlib.o
gcc.compile.c++ bin.v2\libs\iostreams\build\gcc-mingw-4.5.2\release\link-static\threading-multi\bzip2.o
gcc.compile.c++ bin.v2\libs\iostreams\build\gcc-mingw-4.5.2\release\link-static\threading-multi\file_descriptor.o
gcc.compile.c++ bin.v2\libs\iostreams\build\gcc-mingw-4.5.2\release\link-static\threading-multi\mapped_file.o
gcc.archive bin.v2\libs\iostreams\build\gcc-mingw-4.5.2\release\link-static\threading-multi\libboost_iostreams-mgw45-mt-1_46_1.a
common.copy stage\lib\libboost_iostreams-mgw45-mt-1_46_1.a
bin.v2\libs\iostreams\build\gcc-mingw-4.5.2\release\link-static\threading-multi\libboost_iostreams-mgw45-mt-1_46_1.a
        1 file(s) copied.

I don't really know what to make of the build.log files. It's apparently not finding any of the things it's looking for, though the file libboost_iostreams-mgw45-mt-1_46_1.a does exist.

[loonycyborg]

Well, everything is fine with boost compile, however it seems that it fails to link against bzip 2 in the test program even though it uses -lbz2. That's weird. Perhaps whatever bzip2 that you're using with scons is incompatible with bzip2 used in boost compile? Or something is wrong with that bzip2? maybe it's 64-bit vs 32-bit system or something?