Personal checkpoint.

[external/binutils.git] / README.configure

                   On Configuring Development Tools

         Last Mod Sat Apr 13 19:45:44 PDT 1991, by rich@sendai


INTRO
-----

    This document attempts to describe the general concepts behind
    configuration of the Cygnus Support release of the GNU Development
    Tools.  It also discusses common usage.  For a more in succint
    description, please refer to the man page on "configure" which you
    should have received {FIXME: ALONG WITH LOTS OF OTHER VERY PRETTY
    HARD COPY OR IN A DIFFERENT DISTRIBUTION OR ON THIS TAPE OR SHRINK
    BOX OR SOMETHING}.


BASICS
------

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
    several 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:

    In this document, the word "host" refers to the environment in
    which this source 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.

    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, chosing
    infix might be:

        configure sun3 +notation=infix

    while a sun4 with postfix might be:

        configure sun4 +notation=postfix

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

        configure sun4 +forcesubdirs +notation=postfix
        configure sun3 +forcesubdirs +notation=infix

    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.  A second
    configuration overwrote the first.  We've chosen to retain this
    behaviour so the "+forcesubdirs" configuration option is 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 "+forcesubdirs" 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
    $(destdir).  All user visible programs will be installed in
    $(destdir)/bin.  All other programs and files will be installed in
    a subdirectory of $(destdir)/lib.  For the tools in this
    directory, the files not normally user visible will be installed
    in $(destdir)/lib/gcc.

    You can elect to change $(destdir) only as a configuration time
    option.

        configure sun4 +notation=postfix +destdir=/local

    Will configure the source such that:

        make install

    will put it's programs in /local/bin and /local/lib/gcc.  If you
    change $(destdir) 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 and
    move on to the application that resides in these directories,
    namely, the source to a development environment.


SPECIFICS
---------

    The GNU Development Tools can be built on a wide variety of hosts.
    So, of course, they must be configured.  Like the last example,

        configure sun4 +destdir=/local
        configure sun3 +destdir=/local

    will configure the source to be built in subdirectories, in order
    to keep the intermediate pieces separate, and to be installed in
    /local.

    When built with suitable development environments, these will be
    native tools.  We'll explain the term "native" later.


BUILDING DEVELOPMENT ENVIRONMENTS
---------------------------------

    The Cygnus Support GNU development tools can not only be built
    with a number of host development environments, they can also be
    configured to create a number of different development
    environments on each of those hosts.  We refer to a specific
    development environment created as a "target".  That is, the word
    "target" refers to the development environment produced by
    compiling this source and installing the resulting programs.

    For the Cygnus Support GNU development tools, the default target
    is the same as the host.  That is, the development environment
    produced is intended to be compatible with the environment used to
    build the tools.

    In the example above, we created two configurations, one for sun4
    and one for sun3.  The first configuration is expecting to be
    built in a sun4 development environment, to create a sun4
    development environment.  It doesn't necessarily need to be built
    on a sun4 if a sun4 development environment is available
    elsewhere.  Likewise, if the available sun4 development
    environment produces executables intended for something other than
    sun4, then the development environment built from this sun4
    configuration will run on something other than a sun4.  From the
    point of view of the configuration system and the GNU development
    tools source, this doesn't matter.  What matters is that they will
    be built in a sun4 environment.

    Similarly, the second configuration given above is expecting to be
    built in a sun3 development environment, to create a sun3
    development environment.

    The development environment produced, is a configuration time
    option, just like $(destdir).

        configure sun4 +destdir=/local +target=sun3
        configure sun3 +destdir=/local +target=sun4

    In this example, like before, we create two configurations.  The
    first is intended to be built in a sun4 environment, in
    subdirectories, to be installed in /local.  The second is also
    intended to be build in a sun4 environment, in subdirectories, to
    be installed in /local.

    Unlike the previous example, the first configuration will produce
    a sun3 development environment, perhaps even suitable for building
    the second configuration.  Likewise, the second configuration will
    produce a sun4 development environment, perhaps even suitable for
    building the first configuration.

    The development environment used to build these configurations
    will determine the machines on which the resulting development
    environments can be used.


A WALK THROUGH
--------------

Native Development Environments:

    Let us assume for a moment that you have a sun4 and that with your
    sun4 you received a development environment.  This development
    environment is intended to be run on your sun4 to build programs
    that can be run on your sun4.  You could, for instance, run this
    development environment on your sun4 to build our example desk
    calculator program.  You could then run the desk calculator
    program on your sun4.

    The resulting desk calculator program is referred to as a "native"
    program.  The development environment itself is composed of native
    programs that, when run, build other native programs.  Any other
    program is referred to as "foreign".  Programs intended for other
    machines are foreign programs.

    This type of development environment, which is by far the most
    common, is refered to as "native".  That is, a native development
    environment runs on some machine to build programs for that same
    machine.  The process of using a native development environment to
    build native programs is called a "native" build.

        configure sun4

    Will configure this source such that when built in a sun4
    development environment, with a development environment that
    builds programs intended to be run on sun4 machines, the programs
    built will be native programs and the resulting development
    environment will be a native development environment.

    The development system that came with your sun4 is one such
    environment.  Using it to build the GNU Development Tools is a
    very common activity and the resulting development environment is
    very popular.

        make all

    will build the tools as configured and will assume that you want
    to use the native development environment that came with your
    machine.

    Using a development environment to build a development environment
    is called "bootstrapping".  The Cygnus Support release of the GNU
    Development Tools is capable of bootstrapping itself.  This is a
    very powerful feature that we'll return to later.  For now, let's
    pretend that you used the native development environment that came
    with your sun4 to bootstrap the Cygnus Support release and let's
    call the new development environment stage1.

    Why bother?  Well, most people find that the Cygnus Support
    release builds programs that run faster and take up less space
    than the native development environments that came with their
    machines.  Some people didn't get development environments with
    their machines and some people just like using the GNU tools
    better than using other tools.

    While you're at it, if the GNU tools produce better programs, maybe
    you should use them to build the GNU tools.  It's a good idea, so
    let's pretend that you do.  Let's call the new development
    environment stage2.

    So far you've built a development environment, stage1, and you've
    used stage1 to build a new, faster and smaller development
    environment, stage2, but you haven't run any of the programs that
    the GNU tools have built.  You really don't yet know if these
    tools work.  Do you have any programs built with the GNU tools?
    Yes, you do.  stage2.  What does that program do?  It builds
    programs.  Ok, do you have any source handy to build into a
    program?  Yes, you do.  The GNU tools themselves.  In fact, if you
    use stage2 to build the GNU tools again the resulting programs
    should be identical to stage2.  Let's pretend that you do and call
    the new development environment stage3.

    You've just completed what's called a "three stage boot".  You now
    have a small, fast, somewhat tested, development environment.

        make bootstrap

    will do a three stage boot across all tools and will compare
    stage2 to stage3 and complain if they are not identical.

    Once built,

        make install

    will install the development environment in the default location
    or in $(destdir) if you specified an alternate when you
    configured.  In fact, you can skip the "make all" part and just
    "make install" which will make sure that the development
    environment is built before attempting to install anything.  Even
    better, for configurations where host is the same as target, like
    this one, "make install" will make sure that a "make bootstrap" is
    done before installing anything.

    Any development environment that is not a native development
    environment is refered to as a "cross" development environment.
    There are many different types of cross development environments
    but most fall into one of FIXME basic categories.


Emulation Environments:

    The first category of cross development environment is called
    "emulation".  There are two primary types of emulation, but both
    types result in programs that run on the native host.

    The first type is "software emulation".  This form of cross
    development environment involves a native program that when run on
    the native host, is capable of interpreting, and in most aspects
    running, a program intended for some other machine.  This
    technique is typically used when the other machine is either too
    expensive, too slow, too fast, or not available, perhaps because
    it hasn't yet been built.  The native, interpreting program is
    called a "software emulator".

    The GNU Development Tools do not currently include any software
    emulators.  Some do exist and the GNU Development Tools can be
    configured to create simple cross development environments for
    with these emulators.  More on this later.

    The second type of emulation is when source intended for some
    other development environment is built into a program intended for
    the native host.  The concept of universes in operating systems
    and hosted operating systems are two such development
    environments.

    The Cygnus Support Release of the GNU Development Tools can be
    configured for one such emulation at this time.

        configure sun4 +ansi

    will configure the source such that when built in a sun4
    development environment the resulting development environment is
    capable of building sun4 programs from strictly conforming ANSI
    X3J11 C source.  Remember that the environment used to build the
    tools determines the machine on which this tools will run, so the
    resulting programs aren't necessarily intended to run on a sun4,
    although they usually are.  Also note that the source for the GNU
    tools is not strictly conforming ANSI source so this configuration
    cannot be used to bootstrap the GNU tools.


Simple Cross Environments:

        configure sun4 +target=a29k

    will configure the tools such that when compiled in a sun4
    development environment the resulting development environment can
    be used to create programs intended for a sun3.  Again, this does
    not necessarily mean that the new development environment can be
    run on a sun4.  That would depend on the development environment
    used to build these tools.

    Earlier you saw how to configure the tools to build a native
    development environment, that is, a development environment that
    runs on your sun4 and builds programs for your sun4.  Let's
    pretend that you use stage3 to build this simple cross
    configuration and let's call the new development environment
    gcc-a29k.  Remember that this is a native build.  Gcc-a29k is a
    collection of native programs intended to run on your sun4.
    That's what stage3 builds, programs for your sun4.  Gcc-a29k
    presents an a29k development environment that builds programs
    intended to run on an a29k.  But, remember, gcc-a29k runs on your
    sun4.

    Building gcc-a29k is also a bootstrap but of a slightly different
    sort.  We call gcc-a29k a simple cross environment and using
    gcc-a29k to build a program intended for a29k is called "crossing
    to" a29k.  Simple cross environments are the second category of
    cross development environments.



































    if configured for host sun4 and target sun4, this implies that we
    will compile on a sun4 to create a sun4 compilation environment.
    If configured for host sun3 and target a29k, this implies that we
    will compile on a sun3 to create an a29k compilation environment.

    Host sun3 only implies that the source will be compiled on a sun3.
    In fact, it need not be actually compiled on a sun3.  If the
    appropriate native development tools, header files, libraries, and
    operating system support were available on a foobox, then source
    configured for a sun3 could be compiled on a foobox, resulting in
    a development environment for, using the previous example
    host+target pair, "a29k" on the foobox.  Similarly, if the
    appropriate cross development tools, header files, and libraries
    were available on a dec3100, then source configured for host sun3
    could be cross compiled to create an a29k development environment
    intended to be run on a sun3.


Usage:

Gdb's config has features not yet present in the uniform configuration
scheme described here.  For this reason, configuration of gdb must
currently be done separately from that of the rest of this package.
This will be corrected soon.  For more information on the
configuration of gdb, please refer to the documents in gdb.{your
target} if it exists, otherwise gdb.

By "configures", I mean that links, Makefile, .gdbinit, and
config.status are built.  Configuration is always done from the source
directory.

* "./configure name" configures this directory, perhaps
  recursively, for a single host+target pair where the host and target
  are both "name".  If a previous configuration existed, it will be
  overwritten.

* "./configure +host=hostname targetname" configures this
  directory, perhaps recursively, for a single host+target pair where
  the host is hostname and target is targetname.  If a previous
  configuration existed, it will be overwritten.

* "./configure +forcesubdirs +host=hostname targetname" creates
  a subdirectories Host-hostname and
  Host-hostname/Target-targetname and configures
  Host-hostname/Target-targetname.  For now, makes should be
  done from Host-hostname/Target-targetname.  "./configure +f
  name" works as expected.  That is, it creates Host-name and
  Host-name/Target-name and configures the latter.


Hacking configurations:

The configure scripts essentially do three things, create
subdirectories if appropriate, build a Makefile, and create links to
files, all based on and tailored to, a specific host+target pair.  The
scripts also create a .gdbinit if appropriate but this is not
tailored.

The Makefile is created by prepending some variable definitions to a
Makefile template called Makefile.in and then inserting host and
target specific Makefile fragments.  The variables are set based on
the chosen host+target pair and build style, that is, if you use
subdirectories or not.  The host and target specific Makefile
may or may not exist.  If fragments 

* Makefiles can be editted directly, but those changes will eventually
  be lost.  Changes intended to be permanent for a specific host
  should be made to the host specific Makefile fragment.  This should
  be in ./config/hmake-host if it exists.  Changes intended to be
  permanent for a specific target should be made to the target
  specific Makefile fragment.  This should be in ./config/tmake-target
  if it exists.  Changes intended to be permanent for the directory
  should be made in Makefile.in.  To propogate changes to any of
  these, either use "make Makefile" or re-configure from the source
  directory.

* configure can be editted directly, but those changes will eventually
  be lost.  Changes intended to be permanent for a specific directory
  should be made to configure.in.  Changes intended to be permanent
  for all configure scripts should be made to configure.template.
  Propogating changes to configure.in requires the presence of
  configure.template which normally resides in the uppermost directory
  you received.  To propogate changes to either configure.template or
  a configure.in, use "configure +template=absolutepathtothetemplate".
  This will configure the configure scripts themselves, recursively if
  appropriate.

* "configure -srcdir=foo" is not supported yet.  At the moment, things
  will probably be configured correctly only for leaf directories, and
  even they will not have paths to libraries set properly.