RE: Next release

["Weddington, Eric" <eweddington at cso dot atmel dot com>]

> -----Original Message-----
> From: Brian Dessent [mailto:brian@dessent.net] 
> Sent: Friday, August 15, 2008 3:44 PM
> To: David Daney
> Cc: Weddington, Eric; Tristan Gingold; 
> binutils@sourceware.org; Daniel Jacobowitz
> Subject: Re: Next release
> 
 
> 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. 

That always seemed like anomalies to me. What good is it to have support for a target in binutils, but not in gcc, and vice versa.
 
> As I see it they are separate projects and superficially 
> combining them
> doesn't really seem like it would accomplish much, especially 

I was intimating that binutils would, perhaps, benefit from being tied to gcc's release schedule one two fronts: one, it would ensure that it gets released in a timely manner on a regular schedule, as it seems there are more volunteers doing the releasing; two, it could potentially help with compatibility issues, i.e. one wouldn't have to say "use gcc version >= x with binutils release >= y".

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

And it could be argued that that freedom is of marginal usefulness, at best. Is binutils *that* much buggier than gcc, that it is *so* incredibly useful to decouple the two to upgrade the assembler and linker with bug fixes, separate from gcc? At this point, gcc releases more often than binutils... I've seen more frequent gdb releases than binutils.

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

Agreed.

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

No, I was not trying to suggest such a huge change in behavior. The separate process pipeline model is fine with me.

I was merely curious as to the reasons for such a continued *project* separation (purposely ignoring "historical" reasons). It just seems bizarre to me that binutils and gcc enjoy such a good coupling, many of the same people work on both projects, yet gcc has 4 release managers, but Daniel doesn't have time to do a binutils release and is looking for volunteers...