Home Original page

Next release

Brian Dessent brian@dessent.net
Fri Aug 15 23:26:00 GMT 2008 
David Daney wrote:

> My $0.02: Although possible, it would make the release process too cumbersome.  Bugs in any one component would block the release of the entire bundle.  Letting the individual projects progress somewhat independently as they do now allows for more and better releases of all of them.

Not to mention that it would be rather awkward for the targets that
binutils supports that gcc doesn't (random example, i960), or the
targets that gcc supports that binutils doesn't, like Mach-o/Darwin. 
You'd be forcing those users to download a great deal of code that they
don't need and can't even use.

As I see it they are separate projects and superficially combining them
doesn't really seem like it would accomplish much, especially since the
Cygnus combined tree option has always existed for those that do want to
bootstrap an entire toolchain at once.

If anything it would remove freedoms that exist now, like the ability to
upgrade the assembler or linker to pick up bug fixes without having to
also upgrade to a whole new compiler version at the same time.  (To be
fair, I suppose some people would also say that this need to manually
choose a coupling that is compatible is a liability rather than an
asset.)  You could always disable those parts of the tree you don't want
to build, but I tend to think that if the combined tree becomes the
default then the ability to selectively build invidual pieces would just
bitrot from lack of testing exposure.  And anyway you lose this entirely
if you go the extra step of actually integrating the assembler into the
compiler instead of continuing the separate process pipeline model,
which I think is what the OP was suggesting.

Brian
More information about the Binutils mailing list