Making Software

Building software is complicated because source code must be treated in a very specific manner to create a usable binary program — let alone an optimized one. Programmers have developed tools for building software, specifically to hide this complexity. The main software-building tool is called make(1). Make looks in the current directory for a file called Makefile, which contains instructions for the computer to follow. Makefiles can be long and complicated creatures, and you don't really have to know their internals, so we're not going to dissect one here.

Each Makefile includes various targets, or types of instructions, to carry out. For example, "make install" tells make(1) to check the Makefile for a process called "install." If make(1) finds such a procedure, it will execute it. Each target contains one basic step in building, installing, or configuring a piece of software. Make(1) can also perform a huge variety of functions, some of which far outstrip the original intentions of its creators. But it seems that's the fate of all good UNIX programs.

Source Code

Source code is the human-readable instructions for the actual machine code that makes up a program. You might have already been exposed to source code in some form. If you've never seen source code before, take a look at the various files under /usr/src. Here's a snippet of source code from an indispensable OpenBSD program, fortune(6):

 if (All_forts && offensive != NULL) {   path = offensive;   if (was_malloc)     free(path);   offensive = NULL;   was_malloc = TRUE;   DPRINTF(1, (stderr, "\ttrying \"%s\"\n", path));   file = off_name(file);   goto over; } 

Once you have the source code for a program, installing it is pretty straight-forward. You build (or compile) the program on the operating system and architecture you want it to run on. (If you're extremely skilled, you can cross-compile a program on a different architecture, or even a different operating system. Of course, if you're that skilled, you've probably skipped this section of this book. In any event, the OpenBSD team discourages cross-compiling in the strongest possible terms.) If the program was written for an operating system and architecture that is sufficiently similar to where you're building it, it should work. Once you've built the software successfully on your platform, you can copy the resulting program (or binary) to other identical platforms, and it should run.

Some programs are written well enough that they can be compiled on many different platforms. A few programs specifically include support for widely divergent platforms; for example, the Apache Web server can be compiled and installed on both UNIX-like and properly configured Windows systems just by typing "make install." This is quite uncommon, however, and represents a truly heroic effort by the software developers.

If your software is not written so it can compile on your operating system and architecture, your compilation will spew all sorts of horrible errors and fail. In some cases, your compilation will give you all sorts of warnings and seem to complete, but the resulting binary will not function properly or at all.

Crossing Platforms

When you have the source code to a program, a sufficiently skilled sysadmin or programmer can learn why a program won't build or run on a particular system. In many cases, the problem is very simple and can be fixed with minimal effort. This is one reason why access to source code is important.

In the days when every UNIX administrator was a programmer, this debugging absorbed a major portion of the administrator's time. Every UNIX was slightly different, so all systems administrators had to understand the platform a program had been written for, and its differences from their platform, before they could hope to get a chunk of code to run. The duplication of effort was truly obscene.

Slowly, tools such as autoconf and configure were created to help address these cross-platform issues. Still, not every program used these tools, and the tools themselves created their own problems. Systems administrators still had to be able to edit source code and Makefiles just to have a chance of making programs run.