> -----Original Message----- > From: avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org] On > Behalf Of Joerg Wunsch > Sent: Thursday, October 27, 2011 7:27 AM > To: avr-gcc-list@nongnu.org > 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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
