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.
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.
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 -notation=infix
while for a sun4 with postfix you might use:
./configure sun4 -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 -notation=postfix -srcdir=../src) mkdir ../objdir.sun3 (cd ../objdir.sun3 ; ./configure sun3 -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 `-' sign 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'.
NOTE: $(prefix) was previously known as $(destdir).
You can elect to change $(prefix) only as a configuration time
option.
./configure sun4 -notation=postfix -prefix=/local
Will configure the source such that:
make install
will put it's 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.