whoops, lets try that again...


   When we import gdb-5.3 and gcc-3.3.1, will we be keeping the current method
   of using gnu/dist/toolchain or are we going to switch [back] to
   gnu/dist/{gdb,gcc,binutils}?  The latter has the advantage in that it
   directly reflect how the GNU toolchain bits are split into distributions but
   it will mean duplication of some of the binutils bits (bfd, opcodes) and, of
   course, libiberty.


i'd like to split things back up.  there are several reasons for
this, and while i'd really prefer that we didn't from an aesthetic
and code-sharing point of view, maintenence issues seem
significantly more severe with the current method.

rationale for splitting up the merged tools:

        - GCC, GDB & binutils release at different intervals and
	the shared code between them in the latest release is never
	quite identical.  for instance, GDB 5.3 & binutils 2.13.2.1's
	bfd library both had different sets of changes from
	bfd-current such that it was difficult to determine exactly
	what was new and what was old.  that means that we are using
	a different set of libraries for our tools than everyone else
	is, giving potential rise to "netbsd only" bugs.

        - because of the above, updating any single component of the
        toolchain requires extra testing and integration effort than
        should be necessary.  updating toolchain components has
	proven to be difficult, making it simpler helps.  the
	"bfd_read deprecated" messages from GDB in -current are due
	to this sharing.

        - there is some additional work in maintaining two copies
        of libbfd & libopcodes and 3 copies of libiberty.  libibery
        should never be changed, and changes to libbfd & libopcodes
        should not be common, and should always be sent back to the
        FSF anyway.  while this will entail some additional work it
        is likely to be outweighted by the better maintainibility of
        the intree toolchain, and really should only entail applying
	the same patches to both places.


what i'd like to see happen is:

        - import latest versions of gdb, binutils & gcc (any order!)
        into gnu/dist/<foo>.  these are all currently empty (but do
        have old history in some/all cases.)  that won't affect
        anything currently working.

        - split src/tools/toolchain into src/tools/{gcc,binutils,gdb},
        make sure that binutils is built before gcc and only build
        gdb if MKCROSSGDB is set.  (the cross gdb feature is too useful
        to get rid of.)  we should be able to make these use either
        of gnu/dist/{,toolchain/}<foo> with a simple change to the
        path-to-./configure.

        - for mknative, simply split the script into 3 scripts.  it
        is already largely modular and will easily break up.  change
        this to workon the gnu/dist/<foo> versions.

        - for gnu/usr.bin/{gdb,binutils,gcc}, change the makefiles to
        allow for either version.  as ports upgrade to the new versions,
        regenerate their files with mknative (see above).

        - do not use gnu/lib/lib{bfd,opcodes,iberty} for new tools.
        build separate versions between gdb & binutils.  build a shared
        libbfd for binutils and install that into /usr/lib, but build
        a separate static libbfd for gdb.  (hmm, what about ports with
        new binutils but old gdb... then gdb is goin to be wanting the
        new libbfd, which isn't so bad maybe... the alternative is to
        upgrade binutils after gdb... this is a one-time issue.)
	we can just copy gnu/lib/lib{bfd,opcodes} into
	gnu/usr.bin/binutils and build/link/install them from there..


in my mind, the only way we can really have a merged tree is if we
tracked the CVS versions of all tree parts of the tools and i don't
think anyone would want us to do that :-)



.mrg.