On Beta Testing

[AI]

edit - Is the bbcode not working for anyone else?

I've enabled BBCode in your post. It was disabled for some reason (there's a checkbox). Maybe you change your preferences recently?

[Pentarctagon]

I changed my avatar recently, but that's it

Honestly I didn't even know that check-box existed, I looked at "BBCode is ON" under the smilies and thought that meant it was enabled.

[iceiceice]

4) The final 4 checks fail with this:

Code: Select all

Checking for dbus-1... (cached) no
Checking for fribidi >= 0.10.9... (cached) no
Can't find libfribidi, disabling freebidi support.
Checking for Boost unit_test_framework library... no
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 rerun
NLS tools are not present...
NLS catalogue installation is disabled.
utils is not recognized as an internal or external command.

I think these aren't very severe,

• dbus is the linux desktop tray notification system, so it's expected that you won't have that
• I don't actually know what fribidi is but I don't think it is essential
• Boost unit test frame work is an extra boost library used for the "test" executable target, you don't need that unless your build was seriously broken and you wanted to run some sanity checks.
• Hmmm... the NLS thing might actually be somewhat of an issue:
  
  http://lists.freebsd.org/pipermail/free ... 59719.html
  
  According to this thing was at some point required for campaignd and wesnothd (and tools? which might be defunct)
  
  Assuming any of that is still accurate you *might* not be able to build wesnothd without that.
  But also it sounds related to your gettext errors in #3?

So it seems that scons does have fairly significant a speed advantage over code::blocks.

I mean, most likely it's that the other compiler is slightly faster or something. But maybe its also scons

[Pentarctagon]

I do get a wesnothd executable, which I can run without any errors popping up, but it also doesn't seem to do anything either. Just kind of sits there until I kill it with Task Manager.

Then again I've never used it before, so maybe that's normal.

[loonycyborg]

DBus is linux-only inter-process communication protocol. It isn't needed on windows. Fribidi is optional, needed for rendering bidirectional scripts like arabic, even then we won't depend on it directly after switch to pango is complete. Pango has its own internal copy of fribidi. Boost test is needed only for unit test. Your NLS failures are due to absense of msgfmt.exe in %PATH% and won't affect compilation of .cpp files, it's needed only for generation of message catalogs, the .mo files.
Be sure to use dlls from the same source as headers and import libraries. For example, if you were using pango stuff from my wesnoth-deps package to compile, you should take dlls from there too. If something else then use dlls from there.
Wesnothd is a server, you can interact with it but starting wesnoth and telling it to connect to multi-player server at 127.0.0.1.

[Pentarctagon]

Be sure to use dlls from the same source as headers and import libraries. For example, if you were using pango stuff from my wesnoth-deps package to compile, you should take dlls from there too. If something else then use dlls from there.

That fixed the dll issue, thanks.

[iceiceice]

Is there a way to avoid the large download of master and only stick within a particular branch?

I learned recently that the answer is yes: http://stackoverflow.com/questions/4811 ... one-branch

I had apparent success doing it this way:

Code: Select all

$ git clone -b master --single-branch git://github/wesnoth.git
Cloning into 'wesnoth'...

It says you need git version 1.8 at least:

Code: Select all

$ git --version
git version 1.9.1

[Iris]

Because of the way Git branches work, you’ll still get the full history of master up to the point at which the branch diverged. This isn’t too different from a regular clone if you realize that normally the objects in master and maintenance branches are also shared up to each branch’s divergence point.

Code: Select all

shadowm@nanacore:~/src% git clone -b 1.12 --single-branch --no-hardlinks wesnoth wesnoth-1.12-single-branch-test
Cloning into 'wesnoth-1.12-single-branch-test'...
done.
Checking out files: 100% (18593/18593), done.
shadowm@nanacore:~/src% du -sh wesnoth-1.12-single-branch-test/.git
1.8G    wesnoth-1.12-single-branch-test/.git
shadowm@nanacore:~/src% du -sh wesnoth/.git
1.8G    wesnoth/.git

Instead of or in addition to this, you might want to read up on shallow clones.

[sylph]

Pre-googling:

Windows is 64-bit, but I'm using the 32-bit version of the compiler.

I am not a processor person or a systems administrator, but your problem seems obscure. In theory, it could be a problem that the compiler is bit specific. But that sounds like a really bad compiler. 64-bits means that the register windows on the processor has 64-bits and each instruction on the processor pipeline needs 6 sets of gates on some of the pipeline clock cycles. A 32-bit register window would only need 5 sets of gates. (2^6 vs 2^5) More importantly 32 bits can address 2^32 bits (4G) of memory. Whereas 64-bits can address 2^64 bits (16384P) of memory. It might be easier to write a bit-specific compiler, but as far as I know that sounds like an assembler issue. The assembler would know how many bits its platform is. The assembler should be able to translate the appropriate load/store word instructions from the p-code. The whole idea of an HLL (higher level language) is to be platform independent. It makes sense that if somebody would produce a bit-specific compiler it would be Microsoft. Microsoft is good at copying other software companies technologies and making the technologies easier to use and then writing the hardware specifications for the hardware industry to make hardware incompatible with other operating systems.


Post-googling:
I didnt assume Microsoft also goes to such great lengths to make software incompatible. I guess I should have known that.

[iceiceice]

Instead of or in addition to this, you might want to read up on shallow clones.

I messed around with this, it seems that if you use the --single-branch option and --depth 1, you can get the download size from ~3 G down to 1.1 GB. I've added some notes on how to do this to the wiki: WesnothRepository#FAQ

[Pentarctagon]

OK, so this is everything that is needed to compile with scons. I'll be posting a different thread in the next day or two with instructions.

So it seems that scons does have fairly significant a speed advantage over code::blocks.

I mean, most likely it's that the other compiler is slightly faster or something. But maybe its also scons

Forgot to mention, I'm actually pointing both of them at the 32-bit tdm-gcc-4.5.2 compiler that I was told to use in the code::blocks tutorial. So whatever the speedup is, it's entirely from scons.

Though that is based on my assumption that rebuilding the workspace in code::blocks is the same as doing "scons -c" and then building.

[Pentarctagon]

So I was able to get scons to recognize that my boost libraries had bzip2/zlib support by renaming:
libboost_bzip2-mgw45-mt-1_54.a -> libbz2.a
libboost_zlib-mgw45-mt-1_54.a -> libz.a

It compiles and *seems* to run fine, however scons now has a lot of warnings about comparing signed and unsigned variables. Also, after wesnoth has compiled, test.exe fails with tons of "undefined reference" errors. A partial log of them is in the attached file.

[iceiceice]

Hmm, so if I remember correctly, you don't have the boost unit test library, because you weren't intending to compile the unit tests. So if you try to compile the test executable, you should expect tons of linker errors like that. Edit: I guess I thought scons would know not to compile that in this case though?

What did the signed / unsigned warnings look like?

[Pentarctagon]

Looking at it now, it seems they're actually all from boost's test_tools. Is there any way to explicitly tell scons to not use the unit tests?

[iceiceice]

On my machine, by default it does not build the test executable. You can type scons --help, in the wesnoth directory, and it will show you the current options for wesnoth. On mine I have:

Code: Select all

$ scons --help

...
default_targets: Targets that will be built if no target is specified in command line.
    (all|none|comma-separated list of names)
    allowed names: wesnoth wesnothd campaignd cutter exploder test
    default: wesnoth,wesnothd
    actual: wesnoth wesnothd
...

If yours don't look right you might want to reset them with scons default_targets=wesnoth,wesnothd I think.

If I understand correctly, all of the options in this list are "sticky", if you set them to different values once using the command line, they will stay that way until you change them again.

You might also want to check that you are using the "build=release" option and not one of the other variants? But I'm not actually sure if that could affect the targets you are building.

I guess you can also just type scons wesnoth and that should build only wesnoth.