Date: Tue, 10 Feb 2004 11:25:47 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: freebsd-hackers@freebsd.org Subject: New gcc organization in DFly Message-ID: <200402101925.i1AJPlTb047054@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
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@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402101925.i1AJPlTb047054>