[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] RE: AVR toolchain patch hell

From: Eric Weddington
Subject: [avr-gcc-list] RE: AVR toolchain patch hell
Date: Thu, 07 Sep 2006 09:45:17 -0600

Hi Rolf,

> -----Original Message-----
> From: Rolf Ebert [mailto:address@hidden 
> Sent: Wednesday, September 06, 2006 4:23 PM
> To: Eric Weddington
> Cc: 'Joerg Wunsch'; 'Bernd Trog'; Denis Chertykov; Marek 
> Michalkiewicz; Björn Haase; Anatoly Sokolov; Brian Dean; 
> address@hidden
> Subject: Re: AVR toolchain patch hell
> Eric Weddington schrieb:
> This list is an excellent starting point to manage the 
> existing patches, 
> their quality (test, doc status), and their release status 
> (planned and 
> actual). For example the patch for PR23479 has corresponding 
> documentation and test cases and is already applied in the 
> WinAVR binary 
> distribution since several (?) years.

As well as applied in the FreeBSD distro.

> So, I propose to add some more attributes to the bug list:
> - patch exists (yes/no) with link to the latest patch
> - relative gcc/binutils version
> - language (C/C++/Ada) or host system (MinGW) specific patch
> - planned/considered for next/second next release
> (probably it would help to use a naming scheme for the patch 
> files that 
> includes some of the attributes.  That helps in automated 
> build scripts)
> I know that some of the information is readily available in 
> the problem 
> reports themselves.  Nevertheless, it should be shown in the AVR 
> Toolchan Bugs list, too.  The AVR bug list and the PRs have different 
> purposes.  The PRs help managing the corresponding upstream 
> tools, the 
> AVR bug list intends (as I understand it) to give an overview of all 
> open issues in all AVR GNU tools and to coordinate the 
> efforts that have 
> to be spent.  

I agree with you completely. I like the new fields that you propose to add
to the list! I'll see what I can do to add them into the list.

> It takes several months if not years until an existing 
> patch is actually deliverd in a new upstream release of gcc 
> or binutils. 

And that's the real problem: historically it has taken so long to get
changes in the upstream projects, that it has been easier to manage it at
the distro level. But now, with so many needed patches, the coordination
among the distros is getting to be difficult.

>   All this "patch hell" is caused by our appetite to see the 
> enhancements as soon as possible, i.e. in the next release of WinAVR.

And even the other distros too: FreeBSD, Mac, and Various Linux flavours.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]