Re: [Patch] ld config bits for i860 coff target

Re: [Patch] ld config bits for i860 coff target

[Andrew Cagney]

> Hi Guys,
> 
> 
>> Alan Modra <amodra@bigpond.net.au> writes:
> 
> 
>> I agree with Zack.  If we can achieve that, then I think the generated
>> files could be removed from CVS too.  No problem then with churn, which
>> is the major reason to have "blessed" versions of auto-tools.  (At least
>> these days.  When Ian put that version onto the ftp site, there was no
>> released version of auto-tools that worked reliably with binutils.)
>>
>> As I said on irc, I don't really like the idea of recommending a
>> particular autoconf/automake version.  Having an officially blessed
>> version makes us (binutils) lazy in keeping up to date in our
>> Makefile.am/autoconf.ac files, and also means that the latest auto-tools
>> might not be tested as well as they could be.
> 
> 
> Seconded.  If we can make binutils work with modern versions of the
> tools and remove the need to a particular, blessed, version then I am
> all for it.

How quickly people forget :-(

The developer tools came to use specific generated versions of those 
files because people encountered host dependant problems with the 
generators.  Guarenteed that the generated files being run, were 
identical across all fronts.

There is a definite tradeoff - the idealistic (rose coloured) goal of 
things working with any generator tools vs the very real cost to the 
development process caused by people chasing generator bugs rather than 
real problems.

GCC has the luxury of being somewhat insulated from the host - in theory 
it should be completly host independant.  As one moves away from that, 
through the linker and towards the debugger, the dynamics change. 
Botched/unpredictable configure runs really hurt GDB's build.

Andrew

Re: [Patch] ld config bits for i860 coff target

[Daniel Jacobowitz]

On Fri, Aug 15, 2003 at 10:58:26AM -0400, Andrew Cagney wrote:
> How quickly people forget :-(
> 
> The developer tools came to use specific generated versions of those 
> files because people encountered host dependant problems with the 
> generators.  Guarenteed that the generated files being run, were 
> identical across all fronts.

I didn't forget.  If we re-encounter such problems then we can go back
to having blessed tarballs.  Your "idealistic" goal is a lot more
realistic than you seem to think; the autotools have matured a great
deal.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [Patch] ld config bits for i860 coff target

[Andrew Cagney]

> On Fri, Aug 15, 2003 at 10:58:26AM -0400, Andrew Cagney wrote:
> 
>> How quickly people forget :-(
>> 
>> The developer tools came to use specific generated versions of those 
>> files because people encountered host dependant problems with the 
>> generators.  Guarenteed that the generated files being run, were 
>> identical across all fronts.
> 
> 
> I didn't forget.  If we re-encounter such problems then we can go back
> to having blessed tarballs.  Your "idealistic" goal is a lot more
> realistic than you seem to think; the autotools have matured a great
> deal.

Note also that any GCC developer's opinions need to be heavily, if not 
totally discounted when it comes to GDB.  Its GDB, and not GCC that will 
get to sort out GDB's mess.

I'd like to see hard evidence that the proposal works before considering 
an implementation.

Andrew

Re: [Patch] ld config bits for i860 coff target

[Daniel Jacobowitz]

On Fri, Aug 15, 2003 at 12:00:28PM -0400, Andrew Cagney wrote:
> >On Fri, Aug 15, 2003 at 10:58:26AM -0400, Andrew Cagney wrote:
> >
> >>How quickly people forget :-(
> >>
> >>The developer tools came to use specific generated versions of those 
> >>files because people encountered host dependant problems with the 
> >>generators.  Guarenteed that the generated files being run, were 
> >>identical across all fronts.
> >
> >
> >I didn't forget.  If we re-encounter such problems then we can go back
> >to having blessed tarballs.  Your "idealistic" goal is a lot more
> >realistic than you seem to think; the autotools have matured a great
> >deal.
> 
> Note also that any GCC developer's opinions need to be heavily, if not 
> totally discounted when it comes to GDB.  Its GDB, and not GCC that will 
> get to sort out GDB's mess.
> 
> I'd like to see hard evidence that the proposal works before considering 
> an implementation.

I don't see how you could get any evidence without trying the
implementation.  Feel free to do so, in a week or so when I get around
to redoing the conversion for GDB.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer