GCC Install Instructions

[Michael S. Zick <mszick at goquest dot com>]

Sorry for the duplicate post - I forgot to change the subject and address 
lines.

In reference to:
On Monday 12 August 2002 11:28 am, Janis Johnson wrote:
> On Sat, Aug 10, 2002 at 12:32:30AM -0500, Michael S. Zick wrote:
> > 10) The gcc/INSTALL files could use some help - will post something
> > later.
>
> Good, thanks.  The source for these is gcc/doc/install.texi.
>
Text at: <http://gcc.gnu.org/ml/gcc/2002-08/msg00658.html>

While the week's worth of "Cockpit Errors" I made at the keyboard still fresh 
in my mind...
Thread start at: <http://gcc.gnu.org/ml/gcc/2002-08/msg00457.html>

I am considering a two step process:
1) Clarify those install directions for GCC in a manner workable both with 
current GCC requirements and the current workings of other GNU-projects.
<panic>
2) Do a major re-think of those makefiles.  <panic> Actually, what I have in 
mind will re-use about 99.44% of the existing makefiles </panic>.  The 
process will remain the same, only the internal structure will become more 
general.

When I speak here of "makefiles" I naturally, also, mean those files the 
user's Makefile(s) is/are built from.

Item (2) above is at the "Comment and Reaction" stage for now.

Dealing with item (1) first - a description of the situation as I found it 
from the prospective of a "First Time Builder" of GCC and then a description 
of the sort of "Recommendation(s)" I would like to include in the "Install" 
directions.

Historically (and currently for some GNU projects) where the "<release_name>" 
is the highest level directory in the tar-ball downloaded...

Structure A: (where installation instructions say enter: "./configure")
<some_where>/<release_name>/configure.sh
I.E: Building in the <release_name> directory.

Structure B: (where installation instructions say enter: "../configure")
<some_where>/<release_name>/configure.sh
<some_where>/<release_name>/<build_directory>

Structure C: (where installation instructions say enter: 
"<src_dir>/configure")

<some_where>/<release_name>/configure.sh
<some_where>/<optionally_ a_built_for_directory>/<build_directory>

Currently, (as of the gcc-3.1.1 makefiles, when building (at least) <c, 
Ada>), directory structure (C) is REQUIRED.
(Which means that a "VPATH" capable version of "make" is also REQUIRED.)

Note: If you have a "VPATH" capable version of "make" (at least if you have a 
"VPATH" capable version of GNU-make) then other GNU-projects whose 
"makefiles" are written for either structure (A) or structure (B) but also 
set "VPATH" also work for structure (C).

 - * - * - * -

What I would like to include in the installation instructions is a: 
"Recommended Directory Structure" which would look like this -

Having installed your sources from the release tar-balls, your source 
directory structure will look like:
<some_where>/<release_name>
where "<release_name>" is created by the (FSF) tar-ball you just used.

Now create a directory for building the software into which is parallel to 
(and dis-joint from) the <release_name> directory.  You may use a single 
directory structure for the build, or multiple directories if doing multiple 
builds.
That is, make your build directory structure look like:
<some_where>/<build_directory>
OR:
<some_where>/<any_number_of_build_descriptive_directory(ies)/<build_directory>

Make that build directory your current directory and enter (the correct 
expansion of): <some_where>/<release_name>/configure

 - * - * - * -

Using the building of gcc-3.1.1 as an example, this would give a "source 
directory" structure like so (when combined with the other efforts being 
undertaken to have a "Software Requirements" page(s)):

<some_where>/<gcc-3.1.1>

If the system doesn't have a usable "make":
<some_where>/<make-3.79.1>

If user wants documentation built and system doesn't have a usable "makeinfo":
<some_where>/<texinfo-4.1>

If user wants a new set of "binutils" tools (perhaps to support the 
"--new-c++-abi" option):
<some_where>/<binutils-2.13>

If user wants a new gdb:
<some_where>/<gdb-5.2.1>

And so on, and so forth; for whatever the user needs to support a native 
build, cross build (double-cross) or a Canadian cross build (triple-cross).
All the while maintaining the ability to start the build using one or more 
"any ol' compiler(s)" and set(s) of tools.

Where all of the "<some_where>" portions of the source directory paths may be 
the same, relative, or different, absolute paths as long as they meet the 
"dis-joint" requirement.

 - * - * - * - * -

Moving forward, to "pre-think" item (2)...

Retain the historical sequence of: "configure", "make bootstrap", ["make 
check"], "make install"...

Add the targets for "make prep" and "make prep-check" - perhaps also add a 
single new target "make easy".

"make prep":
Tries to Grok the system's directory structure for the sources of everything 
needed, beginning with the recommended directory structure.  Writes a "fill 
in the blanks" script file WITH DIRECTIONS for anything it can't resolve a 
single path too (multiple versions of a needed source, versions on a remote 
system that isn't mounted when the command is run, etc.)

[Avoiding the case where messges like: "Can't make the documents because your 
makeinfo is too old" that fly by among a zillion other messages.]

After the user updates the generated file:

"make prep-check":
Will simply (??) check for a usable source(s) directory structure based on 
the user's updates to the path information of (above) generated file.
Ending with directions to the user to enter either:
"./configure" or "./configure --site=<generated_and_edited_filename>"

At which point the "First Time Builder" joins the path taken by the "Old 
Pros".

Comments?  Suggestions?

Mike

PS: I don't think the changes to the install instructions will take a 
copyright assignment - those are trival clarifications.  The changes to all 
of the "makefile" stuff are fairly extensive, so I need that link to the 
copyright assignment form please.