Go to the first, previous, next, last section, table of contents.

# Some Basic Terms

There are a lot of terms that are frequently used when discussing development tools. Most of the common terms have been used for many different concepts such that their meanings have become ambiguous to the point of being confusing. Typically, we only guess at their meanings from context and we frequently guess wrong.

This document uses very few terms by comparison. The intent is to make the concepts as clear as possible in order to convey the usage and intent of these tools.

Programs run on machines. Programs are very nearly always written in source. Programs are built from source. Compilation is a process that is frequently, but not always, used when building programs.

- Host Environments: Host Environments
- Configuration Time Options: Configuration Time Options

## Host Environments

In this document, the word host refers to the environment in which the source in question will be compiled. host and host name have nothing to do with the proper name of your host, like ucbvax, prep.ai.mit.edu or att.com. Instead they refer to things like sun4 and dec3100.

Forget for a moment that this particular directory of source is the source for a development environment. Instead, pretend that it is the source for a simpler, more mundane, application, say, a desk calculator.

Source that can be compiled in more than one environment, generally needs to be set up for each environment explicitly. Here we refer to that process as configuration. That is, we configure the source for a host.

For example, if we wanted to configure our mythical desk calculator to compile on a SparcStation, we might configure for host sun4. With our configuration system:

    cd desk-calculator ; ./configure sun4

does the trick. `configure` is a shell script that sets up Makefiles, subdirectories, and symbolic links appropriate for compiling the source on a sun4.

The host environment does not necessarily refer to the machine on which the tools are built. It is possible to provide a sun3 development environment on a sun4. If we wanted to use a cross compiler on the sun4 to build a program intended to be run on a sun3, we would configure the source for sun3.

    cd desk-calculator ; ./configure sun3

The fact that we are actually building the program on a sun4 makes no difference if the sun3 cross compiler presents an environment that looks like a sun3 from the point of view of the desk calculator source code. Specifically, the environment is a sun3 environment if the header files, predefined symbols, and libraries appear as they do on a sun3.

Nor does the host environment refer to the the machine on which the program to be built will run. It is possible to provide a sun3 emulation environment on a sun4 such that programs built in a sun3 development environment actually run on the sun4. This technique is often used within individual programs to remedy deficiencies in the host operating system. For example, some operating systems do not provide the `bcopy` function and so it is emulated using the `memcpy` funtion.

Host environment simply refers to the environment in which the program will be built from the source.

## Configuration Time Options

Many programs have compile time options. That is, features of the program that are either compiled into the program or not based on a choice made by the person who builds the program. We refer to these as configuration options. For example, our desk calculator might be capable of being compiled into a program that either uses infix notation or postfix as a configuration option. For a sun3, to choose infix you might use:

    ./configure sun3 --enable-notation=infix

while for a sun4 with postfix you might use:

    ./configure sun4 --enable-notation=postfix

If we wanted to build both at the same time, the intermediate pieces used in the build process must be kept separate.

    mkdir ../objdir.sun4
    (cd ../objdir.sun4 ; ../configure sun4 --enable-notation=postfix --srcdir=../src)
    mkdir ../objdir.sun3
    (cd ../objdir.sun3 ; ../configure sun3 --enable-notation=infix --srcdir=../src)

will create subdirectories for the intermediate pieces of the sun4 and sun3 configurations. This is necessary as previous systems were only capable of one configuration at a time. Otherwise, a second configuration would write over the first. We've chosen to retain this behaviour so the obj directories and the `--srcdir` configuration option are necessary to get the new behaviour. The order of the arguments doesn't matter. There should be exactly one argument without a leading ``-'` and that argument will be assumed to be the host name.

From here on the examples will assume that you want to build the tools in place and won't show the `--srcdir` option, but remember that it is available.

In order to actually install the program, the configuration system needs to know where you would like the program installed. The default location is ``/usr/local'`. We refer to this location as `$(prefix)`. All user visible programs will be installed in ```$(prefix)`/bin'`. All other programs and files will be installed in a subdirectory of ```$(prefix)`/lib'`.

You can only change `$(prefix)` as a configuration time option.

    ./configure sun4 --enable-notation=postfix --prefix=/local

Will configure the source such that:

    make install

will put its programs in ``/local/bin'` and ``/local/lib/gcc'`. If you change `$(prefix)` after building the source, you will need to:

    make clean

before the change will be propogated properly. This is because some tools need to know the locations of other tools.

With these concepts in mind, we can drop the desk calculator example and move on to the application that resides in these directories, namely, the source to a development environment.

Go to the first, previous, next, last section, table of contents.