RE: [avr-libc-dev] Re: [bug #21410] Incorrect use of 16-bit eepromaddresses in devices with 8-Bit address registers

[Eric Weddington]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, October 24, 2007 6:28 AM
> To: address@hidden
> Subject: [avr-libc-dev] Re: [bug #21410] Incorrect use of 
> 16-bit eepromaddresses in devices with 8-Bit address registers
> 
> As Wouter van Gulik wrote:
> 
> > What is the main reason not to build a per-device lib, apart from
> > the time to do such a thing? I quickly scanned the mailing archives
> > but I could only find the build time as a reason. Is this still
> > valid?
> 
> Basically yes.  With the current number of AVRs we are supporting (and
> Eric adding  another dozen or  so right now),  the build time  for the
> entire  avr-libc project  could easily  reach something  like  half an
> hour, which is way too long.  

I think that argument is bogus. It is only the toolchain distro maintainers
and the avr-libc developers that have to eat up that time. I think that is
reasonable considering the value of the feature. Besides, we need to get you
a faster machine, Joerg. ;-)

IMHO, the biggest issue is the amount of developer time needed to make the
change, the resulting testing, and the other reason you mention below:
 
> If we were to change the model to a per-device library one, we'd also
> have to think of a good transition scheme, because this library model
> scheme is hand-wired into the GCC (compiler driver) code.  So it's not
> only we need a new avr-libc but also a new GCC.  One possible option
> for that is to start with avr-libc building per-device *and*
> per-architecture libraries for quite some time, and only then start
> modifying GCC.

And *that* is the biggest reason why it hasn't been done yet. Coordinating
the two projects.

Eric