Alternatives, part II

You may already know that I have some complaints about pidgin:
– its developers use a brain damaged dvcs (yes monotone sucks, yet another application written in C++ that sucks after cmake)
– The ability to listen to the user feedback is severely reduced.

Since we are talking about alternatives looks like somebody tried to make things a little nicer and forked the code so far and made something fun out of that.

Seems promising, I hope it works well enough to be put on Gentoo soon if the pidgin devs don’t come to their senses =P

Replacements and stuff

I’m completely unhappy of the result of those elections, obviously I cannot tell it was unexpected (Idiots watching TV and believing are quite many) anyway today I’ll write about alternatives.

You know that I consider cmake one of the worst item available if you want to get a build system sane. I know that people usin cmake won’t use those alternatives, most of the time because they aren’t that known, fashionable or with spiffy names.
My list
– linux (kbuild) or ffmpeg like systems (note, we need to find a name for it) since those are relatively hard to get working on new projects,
– quagmire seems to provide something you can use but is still its infancy, yet I’ll give a stab at it.
– waf seems scons done right, still it lacks the completeness and ease you can archive using the autotools the right way (reusing the good .m4 bits from aclocal and not wasting time rewriting stuff every time)
– bitbake could make some windows oriented people happy while giving the rest of the world the tools expected, but maybe those people cannot stand an heavy known markup (xml based) while loving the cmake’s one.
– autotools have the main issue that some part of them are either over engineered (libtool) or annoyingly broking from release to release (automake), still the most useful part now it’s autoconf, but iff ffmpeg configure would be chopped into the right bits to be reusable w/out feeling the pain even it could be replaced with ease, recently I discovered dolt, a replacement for libtool that maybe could help a bit.

Right now if you want to build a project autotools, with all their defects and glitches, are the best all around. If you want to get something saner probably you may start looking at dolt and quagmire, if you want to do something for everybody you may start modularizing ffmpeg configure and makefiles or linux kbuild so everybody could enjoy it. In the middle I put other tools that look more or less useful but that for a reason or another I dislike a little.

In a perfect world we don’t have people wanting to use microsoft visual studio to build opensource projects, every library would provide a pkg-config file with all we need to know to link against it, and every system has a identical way to build shared libraries (passing –shared to the compiler and linker?).

In a perfect world probably we won’t witness human stupidity with a Berlusconi III (the government).

PS: The hunt to .la files is open, please try to remove them from your system and tell us if something must be fixed. The treasure trove about pkg-config files is opened too, if you find a library not exposing one please notify us and upstream possibly with a pkg-config for them ^^

cmake and openwengo, what a match…

Quick and easy task for this day: check which is the status of openwengo since seems that’s the only client providing what skype does, at least in theory…

Part one, get the source – delivered from the site as a nifty .zip

– wget + unzip worked as should

Part two, build the beast.

– cmake! The worst build system since imake, sadly brought into the fashionable stuff because of KDE4,
Now we get something interesting, on a phenom you get:

qlop -tH cmake
cmake: 5 minutes, 12 seconds for 1 merges

A comparison:
perl: 3 minutes, 43 seconds for 1 merges
m4: 29 seconds for 1 merges
automake: 14 seconds for 3 merges
autoconf: 16 seconds for 2 merges
libtool: 44 seconds for 1 merges
make: 30 seconds for 1 merges
cmake: 5 minutes, 12 seconds for 1 merges

Using something less new makes the whole thing even more interesting. Let’s say that to build something using cmake I need the 3/2 the time to build perl, just to start.

gentoo has an ebuild for it so it it’s just getting it, (why cmake needs xmlrpc-c is a question I’ll left unanswered…)

Now back to openwengo.

I have to create a build dir and run cmake from there, it obviously finds something wrong with ffmpeg even if supposedly it has its stale internal version (remind: ffmpeg changed the include paths some time ago) as fallback (no, you have to run cmake a first time, have it fail, run ccmake, find the right option and turn it on, start again).

I’m not sure if this brain damage is due wengo people or cmake, still I find this annoying. The *oh* so despised configure from autotools can be smarter and does not require that many lines if you know what you are doing…

It still doesn’t take in account that there are different endianess for linux (autotools have a nice builtin for this…)…

Once the thing built (took a while), I just got more or less the same thing I got last time I tried it, looks like the 2.2 isn’t quite up to date and they are working on the new mayor release =/

Back looking for other alternatives for skype =_=

What news?

Lately I started to test some stuff, after hammering openrc inside bsd jails I started to use it on my laptop, the ps3 and the new phenom I bought recently. So far I hadn’t anything to complain but just minor glitches that got promptly addressed by Roy. With the help of the other testers and developer you’ll get baselayout 2 soon and in a pretty good shape.

Feng and felix got quite an overhaul and hopefully I’ll release them once I cleaned up the code:
– felix had lots of experimental stuff added and you may not want it nor look at it right now.
– feng is getting the eventloop reshaped so that you can understand what’s doing w/out losing your sanity.

I’m still waiting for more SoC applications (in particular people willing to learn CELL seems fewer than we’d like) you have this week left to apply!