> : everything else looks great, though i don't really get the point of
> : moving everything in to usr.bin/binutils...i'd just get rid of the
> : binutils directory there entirely.  i think, in particular, moving
> : GDB there is wrong.
> 
> Well, I wanted at least to group those things found in a distribution.  What
> prompted me to move gdb inside was that it uses libbfd (and comes
> from the same Redhat source tree); we've already run into users who forget
> to build bfd before binutils, gas.new, ld.new, and gdb.
> 
> It's... awkward, I'll admit, but as long as gdb comes with a "don't forget
> to build libbfd!!" warning, it can go outside gnu/usr.bin/binutils.

I'm offended!  GDB is not BINUTILS :-)

More seriously, you may want to think a little more about how you're
approaching this.

The expectation is that the GDB, BINUTILS and GCC repositories will
eventually be merged.  To this end, people already have scripts
available that can create local merged source trees and then build
them.  In addition, people making changes to certain sources (eg
libiberty) must merge their change back into the master GCC tree.

However, even if/when GDB, BINUTILS and GCC do get merged, I'd not hold
your breath waiting for a synchronized GDB + BINUTILS + GCC release.

GDB 5.1, which isn't that far away (xmas?) will have far better NetBSD
support (thanks to J.T. and Matthew) than 5.0.  How is that going to be
merged if GDB/BINUTILS are trying to share a common BFD yet the BFD in
5.1 has significant changes?

Anyway, I can see several choices:

	o	largely independant
		GCC, BINUTILS, GDB
		source trees

	o	single unified GDB,
		BINUTILS and GCC source
		tree.

	o	unified GCC+BINUTILS
		but indepedant GDB. The
		consequences of importing
		GDB's are not as serious
		as importing new GCCs or
		BINUTILS.

I don't know which is better for your needs.

	Andrew
	mumble something about head GDB maintainer

PS: While I've your attention.  Assuming you drag in GDB 5.0 and then
make local changes, could you please remember to tweek
gdb/Makefile.in:VERSION so that the GDB identifies its self as something
other than ``GDB 5.0''.  Otherwize, when (not if :-) someone reports a
bug against ``gdb 5.0'' there is no way of determinging which 5.0 they
are refering to. (Oh, and please not 5.0.0.x, I've already been through
that nightmare with 4.18 - I've lost count of how many unofficial
4.18.0.1's there were .... :-)