Sounds good. Any idea on a timeline?

James

>
>
>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.
>
>
>