Corewars source demonstration

To demonstrate how simple it can be to compile from source, we will compile a simulation game called Corewars (see Resources for a link). Here's a note about Corewars from their Web site: "Corewars is a simulation game where a number of warriors try to crash each other while they are running in a virtual computer. The warriors can be written in one of two assembler-like languages called Corewars and Redcode. Corewars is the default language and is easier to learn and understand. Redcode provides more advanced and powerful instructions but also requires more time to learn."

The first step to compiling from source is to download the source code package from the Web site:

• http://download.sourceforge.net/corewars/corewars-0.9.13.tar.gz

Once the code is downloaded, I expand the package.

tar -xvzf corewars-0.9.13.tar.gz

The file is expanded into my current directory. The standard approach is for the source code to be contained in a directory which matches the product name. In this case, it's in a directory called corewars-0.9.13.

I enter into that directory and find the source code, some documentation, configure scripts and README files. Most source packages will come with a file called INSTALL and one called README. You should read these materials before you compile the software. They will usually save you a lot of pain by identifying problems before you have them and advising you of the correct procedures for compiling and installation. Most problems I have had compiling from source were simply because I didn't follow the directions.

The most common next step is to run the configure script. configure is part of the Autoconf package, included with the development tools of your Linux distribution. Quoting Autoconf's package description: "GNU's Autoconf is a tool for configuring source code and Makefiles. Using Autoconf, programmers can create portable and configurable packages, since the person building the package is allowed to specify various configuration options."

The configure script runs a series of tests on the system to determine the best way to compile the package for your distribution and architecture. It then createx a custom Makefile for your system. If there are problems with compiling on your system, configure tells you. configure will usually let you customize the features to be included in the compile, or let you provide parameters about locations of libraries or other needed files so that the package can be compiled successfully. Here we execute configure with no additional parameters:

./configure

Several tests run on the system ultimately end with success. Now build the program using:

make

If the compile has errors, I will need to determine the problems and fix them. This can be non-trivial and may require a good deal of knowledge about your environment and programming in general. If all goes well, we typically install the software with:

make install

The files are copied into the correct areas of the system, file permissions are updated, configuration files are copied and documentation is added to the manual pages.

Now let's test our handiwork by executing the program. It is a graphical program, so you will need to have X running when you start it. The make install which we did above should put the program in our executable path.

corewars

A graphical screen should appear to reward us.

Figure 2. Success!

The topic of corewars rules is outside of the scope of this article, but you will find documentation about this interesting simulation game in the man page (man corewars).

The corewars compile was a typical scenario. There are many possible variations including using switches on the configure script to adjust the features that are compiled into the program, using different commands from the Makefile to adjust how the compile is done, and others.

Since this program was not installed using rpm, there are no entries in the rpm database. If a program doesn't work out after it's been installed, most Makefiles include an uninstall parameter to remove the software:

make uninstall

Bear in mind that working with raw source code does not enter anything into the RPM database. Software installed in this way is unmanaged, so it should be done with care.

Source RPMs

When an RPM is created, there is an artifact called a Source RPM. This is a SPEC file combined with source code designed to build on one or more architectures. This is the best of both worlds! With a source RPM, you can custom compile the software on your system, but the finished product will be an installable RPM rather than the raw binaries. Most packages that are available as a pre-compiled RPM are also available as a SRPM. This can be a simple way to move software across platforms in Linux. When you have success recompiling onto a different platform, consider sharing your finished RPMs with the community.

May the source be with you

If you are new to Linux, installing software has a different approach than what you are used to. However, the RPM approach to installation is elegant and provides new power which you will soon grow to appreciate.

You should become familiar with the options for working with rpms from the console, but for daily use there are front-end interface options to make rpms easier to manage. One was provided by your distribution, and others are available, such as the one in Webmin.

You are not limited by pre-compiled rpms, though. You can take advantage of the open source nature of Linux to compile applications directly from the source code. Compiling is generally easy for a mature project. Remember that code installed from source code will not have an entry in your rpm database. When working with source, consider using source rpms, which combine the power of compiled source with the manageability of rpms.