><-- @(#) $Id: building.html,v 1.5 1995/12/11 03:55:29 robertl Exp $ -->

<h1>"Everything you didn't want to know about building the 
FSF/Cygnus code." </h1>
<i>...or....</i>
<h2>"How I spent my summer vacation" </h2>

This is based on an earlier document that summarized from a discussion
I had with the SCO Skunkworkers when we were preparing this for
inclusion on the Skunkware CD.  <p>

<h3>Overview</h3>	

In any package of this flexibility, there are a number of ways
it can be configured.  Some will surely look at my method and find it
obtuse.  The major rationale of it is that it parallels the method I
use at my day job and that of Cygnus.  Since I will typically build
about eight sets of compilers from the same source tree [ two are used
in this project ] having them each in separate directories really is a
necessity.  There is a very good discussion of the Heterogenous User's Toolkit include in the online documentation.<P> 

The master source is in /usr/cygnus/progressive/src.  Actually,
the 'progressive' in that pathname is a symlink to the specific
Cygnus release that I am working with. <P> 

I create two directories to hold the builds.  One is elf, one is coff.
My convention is to make the ELF release is the more capable of the
two.  For example, the 'nm' command in the ELF tree knows about COFF,
but the 'nm' in the COFF tree does not know about ELF.  It is for this
reason that I include the 'nm' binary frmo the ELF tree.  I no longer
even install the COFF-only binutils, but GCC does pick parts of these
tools and gas for inclusion.  Therefore, we do still have to build them.<P>

In the same place you found this document, you should find a shar file
named 'building-xxxx.shar'.  This will include the shell scripts I use to
configure and build these releases.  Also, you can see how I make them
installable by the SCO custom utility.  Clearly, this example will
tell you much.<p>

The binaries are provided with no debugging, and are stripped.
This is likely to be a problem only if you are debugging the tools
themselves.  If this is the case, you know how to make your own set
with debugging and unstripped.   <P>

Also, to simplify the naming somewhat (and allow reasonable use of the
<code>-b elf</code> flag), I suggest making several symlinks in the
resulting tree.  This is handled by the 'fixup' script included in the
'building' file.<p>

If you have a multiprocessor machine (or cleverly networked machines)
	you can run parallel makes in each of the directories (yes, 
	even with the -j if you have a bunch-o-processors and the 
	GNU make that is provided) at the same time with no bad side 
	effects.<p>

Also included in that sharfile are a number of dorky little tests that
I run to prove that the build works at least moderately well.  It verifies 
that the namespace [ the manifest preprocessor directives ] match those of
the SCO compiler.  It proves that static constructors and destructors
work correctly.  It proves that all the correct libraries and binary
types are built when called with appropriarte flags.  It does not do
full regression testing.  I do that as a separate step.  The 'make check' 
provided by Cygnus/FSF tests the "hard part".  My tests just check specific
things that I've been known to bozo in previous builds.
<p>