New gcc organization in DFly

[Matthew Dillon]

    DFly has incorporated a new organizational structure for gcc3 and
    binutils214 that FreeBSD might want to take a look at.

    Basically it works like this:

    * The vendor code in /usr/src/contrib is named after the major version
      release, so e.g. we have /usr/src/contrib/gcc-3.3 (gcc-3.3-20040126 at
      the moment) and /usr/src/contrib/binutils-2.14

    * The vendor code in contrib is unmodified, with only the addition of
      README files describing the setup and the deletion of all original
      vendor files that the build does not require.

    * The build is represented by /usr/src/gnu/usr.bin/{binutils214,cc3},
      /usr/src/gnu/lib/{gcc2,gcc3}, and so forth.  In DFly, the gcc2 stuff
      was left in bintuils/ and cc/.

    * The intention is so that we can (A) have multiple revs installed on 
      the system simultaniously and (B) physically remove obsolete revs from
      the contrib/ portion of the repository, just leaving the build portion
      in /usr/src/gnu in the repository.  If a developer wants to revert
      to an obsolete rev he can simply download the original vendor tar
      and unpack it into contrib without modification for his local use.

    * binutils-2.14 installs in /usr/libexec/binutils214/{ldscripts,elf,aout}

    * gcc-3.3 installs in /usr/libexec/gcc3 and /usr/lib/gcc{2,3}  (e.g. the
      crt*.o, libgcc, and other version-specific files get a subdirectory
      in /usr/lib).

    * The front-end code, /usr/src/usr.bin/objformat, is made to understand
      the new layout as well as a new environment variable, CCVER, and
      exec's the appropriate binary from the appropriate location.

    * installworld and/or upgrade Makefile's were modified to remove the
      old binaries.

    I'm not entirely finished with it yet.  The gcc-3.3 build still hardwires
    the binutils path, but generally speaking this methodology has worked out
    very well and I am going to start applying it to other contrib stuff
    in the DFly hierarchy.  It makes updating vendor code a whole lot easier..
    a matter of a few minutes rather then a few hours, and allows us to
    maintain very new or experimental vendor code in parallel with the
    production version without effecting the existing user base.  And being
    able to physically delete obsolete revs from the repository is a big plus
    too because modified vendor code creates the worst bloat in a CVS
    repository.  The original impetus for the work was so that we could
    integrate support for other compilers (e.g. TenDRA, ICC) as well as
    future versions of gcc, rather then as port hacks.  We haven't done that
    yet but we now have the infrastructure to be able to.

    FreeBSD might want to review this new methodology for gcc, bintuils,
    and other vendor material (heimdal, openssh, kerberos, openssl, etc).
    I've only managed to convert gcc and binutils so far, and it was a lot
    of work to clean up the build tree in /usr/src/gnu/xxx, but it's work
    that only needed to be done once and much of it is directly transportable
    to the FBsd infrastructure.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>