Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0

[E. Weddington]

Bernardo Innocenti wrote:

> E. Weddington wrote:
>
> > 1. CVS commit policy was reasonable. I don't have any reason to 
> > suspect that it is *not* reasonable, but I am not familiar with their 
> > policies.
>
>
> At least they don't demand signing legal papers as FSF projects do :-)
That's a good thing for me.

> > 2. AVR-specific headers and library code can be easily integrated, 
> > thus no burden on "toolchain distributors", _me included_. :-)
>
>
> I hope they will, but as a toolchain distributor you'd at least
> get binutils + GCC + newlib + GDB all built together.  This is
> already possible today, except that libgloss breaks the build
> and newlib must be replaced with avr-libc at a later stage.
From my point of view, I could care less about building from the 
uberbaum. But I understand it makes some people happy.

> Integrating simulavr so we could run GCC's regression tests
> on the AVR would be great (mainline no longer broken every
> few weeks without anyone noticing).
I think it would be great to integrate simulavr, or now known as 
simulavrxx (even though it is just an internal architecture change, 
there is new management at the simulavr project), and also integrate 
avarice. But also most importantly I would like to have a native Win32 
version of both of those.

> > To give a very concrete example of #2, in avr-libc there is 
> > avr/boot.h which provides an API for creating bootloaders using the 
> > (mega) AVRs bootloader feature. This is certainly a valuable piece of 
> > work that IMO should not get lost when moved over to newlib,
>
>
> If only I knew about that a few months ago... We almost
> rewrote Atmel's bootloader application-note which was based
> on IAR's compiler and used a MS Excel document with VBA
> macros as a replacement for autoconf :-)

Well, that's what documentation is for. ;-) See the avr-libc user manual 
for more info.


> > and toolchain distributors should not be burdened with having to 
> > provide it seperately or maintaining a seperate repository for it. 
> > Another important example is all of the avr-libc string functions 
> > that work with Program Space parameters.
>
>
> If these could be made a little more generic, they would be
> very useful on many Harvard processors.  The RTEMS people
> may like to have something like that in newlib.
I don't know how generic it could be made until GCC actually has a 
generic way of specifying different memory spaces. Right now those 
routines make use of macros in avr-libc to access (read) the program 
memory space of the AVR.

> > Ralf, Bernie, you both have had more experience with newlib than I 
> > have, does all of this sound reasonable? Is there anything that we're 
> > not thinking of here?
>
>
> - newlib and avr-libc have different licenses, altough it seems
>   newlib already includes a few GPL'd files in their codebase
>   and many avr-libc sources still bear the 3-clause BSD license
>   header.
*All* of the avr-libc sources now have the 3-clause BSD license.

> - newlib uses a funny documentation format, avr-libc uses doxygen;
I'm perfectly willing to drop doxygen. In my mind it is too restrictive. 
Joerg will have to state his opinion.

Eric