The 'current-arch' links should definitely not be version-controlled.
Added the current-arch to the ignore list also, to avoid it being accidentally committed in the future.
Set up a basic Rake structure, which will eventually make it possible to build chaos again. The reasons for choosing Rake are basically two:

- To learn how to use Rake :)
- To make it easier to make modifications to the way chaos is built. Clearly, the Perl/XML-based autochaos approach is outdated by now; using 'make' would work but clearly isn't perfect.

Also, since I use Ruby every day at work it feels like a pretty natural choice.
Set up the include/storm/current-arch link automagically, since it must be present for the code to successfully compile.
This one was very unexpected, but it seems like we need to set up the link in a quite weird way to get it rolling.
Remove this current-arch link also when cleaning.
Removed GPL reference and updated copyright.
Thank you, gcc 4.7, for pointing this out… Found and fixed a quite serious bug in the mutex code, which would make unlocking a mutex basically not work at all. :) (spinlock_type = int, i.e. call by value which means the variable cannot be modified lest it is changed to a pointer type.)
Fixed the include/current-arch linking to be done correctly.
Added PACKAGE and VERSION defines, since the debug.c file requires it.
Updated copyright and license header.
This one is really strange; how come process_name no longer exists…? Weird. Let's hope there are no other strange gotchas in the existing codebase… :) The storm/generic folder now compiles, up next is the storm/ia32 folder also.
Use silent mode and no verbosity.
Customized the compilation printing until I was happy with it. ;) Now, the only problem is that we obviously don't want all Rake files to have a bunch of hardwired ANSI codes in them so we have to find a way to have some "common" parts. I did try the approach of loading all Rakefiles into the same Ruby runtime, but it didn't work that well since the current working directory wasn't properly changed. Could look into the ideas suggested by http://stackoverflow.com/questions/1686779/multifile-rake-build sometime; I just got the feeling that they didn't 100% apply to our use case when I checked it today...
Added support for a rakelib, since this will make things a lot more clean. We will then also be able to have a standard set of CFLAGS used for everything (both kernel, libs and servers) which we than can simply append to in cases where we need to have more special flags (storm is one typical example of where this could get needed).
Use print rather than .print since it's much easier to understand, and fixed one more hardwired ANSI code thing...
Moved the verbosity flag to a common_settings.rake file.
Moved out some stuff into a common_rules file, so we don't have to repeat ourselves.
Added basic Rakefile, based on the previous stuff in autochaos.rules. Not yet compiling because of changes in mutex.h
Updated copyright and removed outdated license header.