SDL Sasteroids is a rework of the original Sasteroids game by Brad Pitzel last released in 1994. It allows the original Sasteroids game to be played on modern hardware, without vgalib and older versions of gcc. Old fans of the original will find many suprises in addition to the same old game released years ago.
Re: Be fair
Note: I am the author of the original article.
I think some background information would be useful about this article, I place the blame on autoconf, squarely here, when in retrospect, it should have been placed on lazy developers misusing autoconf. The article was written out of shear frustration of the following:
1. Trying to get an existing (large) project moved over to autoconf instead of traditional makefiles, and having numerous troubles along the way.
2. The fact that at the time, I was working on a linux distribution, and constantly found myself running into poorly written, badly designed, unacceptable configure scripts, or projects that where shipped with only an autogen.sh, relying on you having a copy of configure there. (Where you run into problems with having the right version of autoconf installed.)
I freely admit it was a rant, but I'd like to think that some people at least started looking at the problems with their autoconf scripts and fixing them, because many of the problems I listed, are now, not as apparant. Newer versions of autoconf, and automake have definate improvements, and I'm pleased to be using them, despite the high learning curve. Although, last I checked, documentation was still sorely lacking. Perhaps if I get some spare time, I'll take up your suggestion and write a tutorial for it.
I still think that we could do better though, as evidenced by software like scons, the linux kernel build system, and ant.
> Everyone who uses not Linux but e.g.
> Solaris, the autotools are a great
> thing. If you ever downloaded a packages
> that just uses Makefiles and assues that
> stuff is there where is is under linux,
> then you know what I mean.
> The auto-tools are not optimal and I
> agreee that it is really urgent to put
> all the docs into a shape where they can
> easilly be updated (e.g. docbook via
> media-wiki), but the tools work and are
> somewhat the standart way of doing it.
> Users have aquainted basic knowledge of
> them. If the unpackage something that
> requires them to do something else, then
> the experience is not always better.
> And finally there are ways to make the
> auto-stuff easier. It started with
> packages providing the *-config files
> and continues with having pgk-config.
> The next time, you write such an
> article, please be preceice and fair.
> And if you don't like the state of
> documentation of the autotools, do
> something against that. You are very
> welcome for sure and can earn a lot of
> fame when you are succesful with that
> (definitely more that by writing such an
Hrm. What's with this all green stuff???