Re: [avr-gcc-list] Trouble compiling avr-gcc > 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Joerg Wunsch
> Sent: Thursday, October 27, 2011 7:27 AM
> To: address@hidden
> Subject: Re: [avr-gcc-list] Trouble compiling avr-gcc > 4.4.4 on Mac
OS X
> Leopard with gcc-4.2 (Solved)
> 
> As Jens Bauer wrote:
> 
> > Do you know if there's a reason for this, or is it just because "it
> > doesn't fit in logically" ?
> 
> It is far too AVR-specific to go into a generic toolchain as GNU
> binutils are.  In order for being acceptable there, it would have to
> be designed in a much more generic way, so it at least would become
> applicable to other similar device families (say, all flash
> controllers that are supported).

I agree with Joerg. On this part.

 
> The IMHO better way would have been to continue the old shellscript
> instead, call avr-size as the backend tool, and perform all the
> relative percentage calculations in the script.

In his opinion. ;-)

Mine differs slightly...

> That's the way WinAVR
> started with.

And the reason it changed is because I put together WinAVR, and dealing
with shell scripts and Windows users was not "ideal". It was just easier
to provide functionality as a patch and have it automatically built into
the toolchain, rather than deal with Windows users trying to run a bash
shell script.

Joerg and I keep going back and forth as to which way would have been
better. I concede the fact that because this functionality is highly
unlikely to ever be accepted into the binutils project, that it would be
best to provide a shell script that does the required massaging of the
data. Another advantage of the shell script is that if there is a bug
(e.g. the wrong RAM size of a device, which does seem to happen on a
semi-regular basis) then the end-user can easily fix it just by editing
the shell script (or rather some data table in the shell script which
would be easy to do).

But, I didn't want to maintain *two* different methods: a shell script
and a patch. So I dumped the shell script in favor of maintaining the
patch only. And since no one else stepped up to maintain a separate
shell script in addition to the patch, we are now in the situation we
have today.

Eric