First stop: the installation on Slackware 64. (you may skip this if you run some flavor of Pokemon OS ).

As I mentioned in my previous rant, the developers of Awesome have decided that they’re complete and utter idiots. That is, they forced me through CMake, which usually fills me with anger. Fortunately they didn’t include Boost in the mix, so after some cursing it can be installed.
In order to get Awesome 3.4.3 installed, I needed to:

• Upgrade my xcb-proto to version 1.6 ** (source)
• Upgrade my libxcb to version 1.5 ** (source)
• Upgrade my xcb-util to version 0.3.6 ** (source)
• Install libstartup-notification version 0.10 or higher ** (source)
• Install libxdg-basedir version 1.0.2 or higher ** (source)
• Install libev ** (source)
• ** indicates that the whole ‘wget, tar, configure, make, makepkg’ riddle works fine with my slackbuild.pl script

That was pretty easy with slackbuild.pl. Note that you might have to recompile cairo to enable xcb support (it’s a configure flag that used to be disabled on Slackware). Mine didn’t need it though.
Next is building Awesome. If you don’t want Awesome scattered all over /usr/local/share you might want to give CMake some hints. See my previous rant about setting this permanently.
Today I used this:

After that, ‘make’ should compile it properly, and you can use slackbuild.pl to make a package out of it. (or make DESTDIR=bla, makepkg yadieyada).

Second stop: Testing Awesome

I still like to type startx every time I booted my machine, so for me the thing to change was the file ~/.xinitrc.
Something like:

Kill your X and startx, and voila! The first error.

Awesome's first error!

First impression: looks clean.
A tiny menu bar / panel / whatever you want to call it that shows the running programs and the date.
The default shortcut to do everything seems to be the windows button, or mod4. I’m not sure if I like this, since alt was already cramping my thumb every now and then
However, this can be changed, so no big deal. mod4-enter starts a console. Good. It’s fast too!
Hitting mod4-enter a few times looks like this:

Awesome after hitting mod4-enter a bunch of times

Needless to say there are tons of things to try out and customize, but you might want to check out this guide for starting out with awesome. I did

Maybe it will even replace Fluxbox…. we’ll see. Time to mess around with it some more.
Keep up the good work Awesome developers…. and switch to autoconf!

(put it in a file in /etc/profile.d to have it loaded all the time).
Unfortunately this won’t save you from all CMake builds. For instance I just tried to build Awesome (messing around with a new window manager can be fun sometimes) but when I saw that they use CMake I almost aborted instantly. To make the installation use proper paths you would have to add this to the CMAKE_ARGS for instance:

Ridiculous.

Anyhow, if I still feel like messing around it once it finally compiles I might talk about it later.

Did you know that CMake also fails to create an uninstall target…. gah.
Because oh dear, it might remove useful files from the system. NO SHIT SHERLOCK, WHY DO YOU THINK I WOULD WANT TO RUN AN UNINSTALL?!?!?!
Fortunately it does support DESTDIR, so we can handle the uninstall through our package managers. Phew.

Oh. Boost….. that time of the month. If there’s one piece of trash I’ve run into very often on my compilation expeditions…. it’s boost. What a cancer piece of trash that is. You wouldn’t believe the amount of cursing I’ve gone through on my trails through “build from source” land because of boost. It never works, and when it does it’s limping on. They should have called it “blast” instead.
These days boost is in the official slackware repositories. You’d think that would help, since I can’t mess up the paths etc anymore. (compiling boost is another disaster btw, don’t go there unless you like torture). But noo, as usual the programs that use boost (“because we can’t code ™”, or at least, that’s what I think) are so good at coding stuff themselves that they fail the autoconf for it as well. Prutsers. Well, to be honest, if they can’t code it themselves it’s probably smart to use a library that handles it for them….. but boost? :/

Anyway, back to qBitTorrent. Actually, it’s libtorrent-rasterbar that’s failing. Attempt 1, configure with only a prefix and no other options:

WHat?! Do you ahve Boost::System? Yes. I mean no!
… seriously, who comes up with this shit….
So we dig into config.log and find:

Or in other words: nothing we didn’t already know. FUCK.
Time for a trace.

…. /usr/lib? Says who? Not me, that’s for sure. idiots.
In fact, I’m quite sure that it’s in /usr/lib64.

Jup, as expected. Boost is kanker. Since boost doesn’t have the usual pkgconfig issues, we can only conclude that the reason is that either this configure.in was written by a moron, or that
boost supplies invalid tests for finding itself through the autoconf system. I suspect the latter, but that’s just me

In this case the solution is simple, since the configure script has an override option. Wonder why… maybe they ran into boost idiocies before?
The solution:

This runs through configure, it finds the boost garbage and runs through. And guess what? It even compiles!

The gist of this rant: autoconf is pretty useless if you make assumptions that autoconf is supposed to detect. If you write software, don’t assume this stuff, try to detect it.
Also: when it fails, give me an error message that is useful, not some generic error code. “Library not found” vs “library not found because libblabla.so doesn’t exist in /usr/lib”.

About qbittorrent: it’s a cute little torrent client for linux. Especially if you like faily lightweight stuff that does has a gui. The thing I like about those lightweight clients: they’re fast.
This one even has an RSS reader these days…. cute.
Here’s a screenie:

qbittorrent v1.5.0

So qBittorrent: keep up the good work, and get rid of boost

Needless to say I went for the source ball. Through my famous slackbuild script of course!
That went fine, until configure barfed about some CEGUI thing.
What’s a CEGUI thing?
Apparently it’s some kind of windowing/widget library. Yeah, another one.
So I ram it through slackbuild, which went fine as usual after I did a make distclean in the source dir. Some how the first build fucked up, don’t ask me why.
Anyhow, I installed the CEGUI package and ran back to the smc source dir.
Slackbuild had no other issues this time so out rolled a package. After installation I tried to run it.

Here’s what it said after my screen went black for about a second and came back:

Yeah, that’s what I get for trusting yet another crap library with widgets. *sigh*

However, I had just enough energy left to try one detour into bug/issue fixing land.
Google came up with basically only 1 thing, so after trying my best to read some italian forum I trashed it back through google’s own translation service.
Now that it was in dutch it was a bit more readable, it hinted about using the freeimage library instead of the default TGA codec (which obviously failed).

Installing the freeimage library was pretty trivial, although they don’t use autoconf so I had to go through their Makefiles manually.
The first hint of trouble is usually when source packages come delivered in the famous .zip format. Oh, sorry, I meant .ZIP-EVERYTHING_IS_CAPS format. Seriously, don’t get me started on how many times those kankerthings exploded in my /usr/src dir so far, completely splattering up everything there.
Good thing I’m good with rm. Anyhow, this zip package was decent and created a dir (without version number though).
After fiddling with the makefiles and building freeimage, I also build freeimage plus and stashed it into a package with makepkg.
Phew, sweat on my forehead. Hopefully slackbuild will be able to handle this some day….. (dream on)

Back to CEGUI — compiling it with the freeimage library went without problems, and after upgrading my previous CEGUI package it was finally time to retry SMC.
By the way, did I note that all these packages compiled on x86_64? Good job on that one guys

This time the screen actually came up with some mario^H^Hyo like stuff! Just like the good old days with the SNES!
It looked a bit like this:

On the background the theme music played that reminded me quite a bit of the original snes game.

Messing around with it a bit I quickly got myself killed a few times and had some fun.

I soon realized that the SNES version had better controls, but then again… playing on a keyboard is kinda cramped for platform games.
So I reconnected my Logitech Rumblepad 2 to see if it would work. Well, if works great
Not a snes pad (the thing is a lot like the original playstation controller), but it played a hell of a lot better.

Conclusion: if you’re feeling bored, give it a shot. Good for a bit of fun, and it has a level editor as well!
(which can be seen in this impressive edit I made here

Keep up the good work, guys from SMC!

It’s a tiny little shell script that takes the configure options and barfs out some prefixes and stuff based on the options presented to it.
So when I tell it prefix=/usr, it will decide that sysconfdir=/etc instead of sysconfdir=/usr/etc.

You can get my my version here:
config.site - Version 0.1 - SHA:

Now the important tidbit. In order for configure to automagically use this script, you wil need to set the environment variable CONFIG_SITE.
Personally I do this through a profile file. Download the config.site script, put it in /etc and put the profile file in /etc/profile.d. Logout/login, done.
Oh, here’s the profile file:
config_site.sh - Version 0.1 - SHA: 3a6145987d03811f274ace34f5d08738f266f131

Now if everything worked out allright, running configure should start with something like this:

Wonderful isn’t it?