The new AC adapter died last Sunday during normal operation while the laptop was running on it with the battery at 100%. I was just about to play a game when this happened.

Luckily, I got it replaced the next day and now I'm on bluecore again. I hope this is the last time this happens.

After almost two days of wandering around the streets of the city, my emissaries located a place to buy a new AC adapter for my much beloved HP Pavilion “ATI hellspawn” dv5-1132la, and I have thusly regained access to my development environment for Wesnoth and related projects.

48 hours of using a laptop with a broken display, short-lived (8 minutes) battery, unusable touchpad buttons, different keyboard layout and outdated user config can be very frustrating, but it was a good exercise nevertheless. It's better to have a broken spare laptop running Linux (Debian Lenny before Stable) than no spare laptop or no Linux laptop at all.

My laptop's AC adapter has finally died after passing out in three opportunities. I've already sent my emissaries across the city to find a spare for this thing.

For now, I'm using my old, broken Acer laptop and I won't be available for most of the time until I can use my HP Pavilion dv5-1132la again.

When I got my current HP laptop on December 2008, it was pretty nice to compile Wesnoth from scratch with 3 or 4 parallel compiler instances in less than 15 minutes, even when making -O3 builds.

Nowadays, it can take an hour to make an -O3 build with 1 single compiler instance, and parallel compiling is out of the question. In comparison, Wesnoth 1.0 can be compiled in 3 minutes and a half with 1 single instance, and much less time with -j 4.

Exactly what is wrong with this? Let's take a look at the relevant system stats and compilation settings:

• CPU: AMD Athlon X2 Dual-Core QL-62 (2 GHz each core)
• RAM: 2 GiB minus 256 MiB (onboard graphics)
• OS: Debian GNU/Linux “Squeeze” (amd64) (GCC 4.4.2)
• Kernel: Linux bluecore 2.6.33.2-bluecore261-preempt-suspend2-audit #1 SMP PREEMPT Mon Apr 12 21:38:39 CLT 2010 x86_64 GNU/Linux (Tux-On-Ice patch, optimizations for AMD K8, timer freq. 1000 hz., NO_HZ, PREEMPT)
• Filesystem where .ccache and Wesnoth's source are: ext3 (sda6)
• Filesystem for /tmp: XFS (sda9)
• CXXFLAGS: -pipe -mtune=native -march=native -O3 -Wl,--gc-sections,--relax
• Build system: SCons (ccache=True, fast=True)

-O3 obviously involves extra CPU load at compile time because of the extra optimizations compared to, say, the default -O2. Nonetheless, I know well that it used not to take this long to build Wesnoth at the start of 2009. Wesnoth's code grew a lot over the course of the year due to the introduction of the new AI framework, the new lobby and more GUI2 development. Particularly, if I run scons with -j 2 or greater nowadays, I can run out of free RAM (making Linux page everything out to swap memory) during the compilation of the AI framework.

The most likely reason for this problem is the common use of C++ templates in that code. This feature is used a lot in GUI2 as well, but the code generated by template instantiation on every object file appears to be smaller.

While building stuff from scratch should be relatively uncommon for a developer like me who also has ccache installed and enabled, very minor changes in GUI2 or the AI from other developers currently trigger a near-total recompilation of Wesnoth. I have complained a lot about this in many opportunities, but it seems that I've hit a hard wall as a consequence of Wesnoth's evolution. It has finally become a BFG (Big Fucking Game).

An -O3 executable of the main game target can be as large as 14 MiB. An -O0 debug build with symbols nears 400 MiB, and the directory with the resultant object files (including the executable) reaches 1.4 GiB of size.

Right now I'm considering adding more RAM for other reasons — namely, running Windows XP SP3 on VirtualBox can easily starve the host if certain apps like Iceweasel or Kate are running on the latter. I've yet to see if this will help me compile Wesnoth faster. It won't magically reduce the frequency of full rebuilds, though, and that's really discouraging me from hacking the mainline engine unless it's a one-shoot patch like the one involved in the fix for bug 15902.

The alternative is getting a quad-core machine or a distcc host. The first is least likely to happen.

As I mentioned in my Wesnoth Evolution: 0.1 article, I contacted David White (a.k.a. Dave/Sirp) to ask him a few questions about Wesnoth's early history — more specifically, about codename “strategy” and Wesnoth 0.1.

This is not an all-inclusive interview. You can find more information on Wesnoth's history in Wesnoth.org if you know how and what to search. Wesnoth Philosophy on the wiki (which includes The History of, and Philosophy behind Wesnoth) may be a good starting point.

Without further ado, meet Dave:

Battle for Wesnoth has been around for some years already and its ever increasing content and artwork quality has attracted many code developers, sprite and portrait artists and musicians over time. I started playing Wesnoth on version 0.9.6 which was distributed with the SUSE Linux 10.0 operating system; I later switched to version 1.0.2 and closely followed the 1.1 release cycle.

Now that version 1.8 has been released and approx. 7 years have passed since the very first release, I felt curiosity to see exactly what has changed and what hasn't changed since the very first Wesnoth version published by David White (a.k.a. Sirp) that isn't even available in the downloads page at SourceForge.net. Yep, that's right, this is a review of Wesnoth 0.1 against current versions of Wesnoth such as 1.8 and 1.6, or even intermediate modern versions such as 1.0.

For historical reference I'm using both an actual Wesnoth 0.1 build for Windows I prepared using the Mingw32 cross-compiler environment for Linux (running on WINE), and the Battle for Wesnoth Project's SVN trunk changelog, which starts at version 0.2.1. The project's combined CVS-SVN history, on the other hand, starts on September 15th 2003, 15 days before the first CVS release tag, version 0.4.8. The first version announced since the beginning of the Wesnoth forums (which predate Wesnoth.org itself) is 0.3.7.

Being just two years old, the Wesnoth-UMC-Dev fulfills its mission again and beetlenaut's Dead Water has just entered mainline (about 45 minutes ago)!

Since its inception on March 14th 2008, Wesnoth-UMC-Dev has hosted and served as a staging area for the following mainline campaigns:

• Legend of Wesmere (entered mainline on October 7th 2008, 02:28 UTC)
• Delfador's Memoirs (entered mainline on April 10th 2009, 02:08 UTC)
• Dead Water (entered mainline on April 6th 2010, 17:02 UTC)

When I first installed Debian Lenny on this laptop in December 2008 ­— Lenny was the testing distribution back then — I partitioned the brand new computer's hard disk following some basic ideas I collected from elsewhere, including my own ideas and experience. I knew that I didn't want /home (non-Linux users: this is the directory where my user configuration, files and documents are) to reside in the same partition as things that are being continuously written to (/var, with the log files and other info managed by running services) or stuff that is constantly being read and executed (/usr, /bin, /sbin, /lib).

I know very well (well, basically) how hard disk drives work and that I'm most likely not protecting my files against hardware errors. However, this has still demonstrated to be a good protection against software errors — example here.

My scheme has some major drawbacks, though. Let's take a look at the state of things in “bluecore” (my current HP laptop):