RE: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

[Weddington, Eric]

> -----Original Message-----
> From: Ruud Vlaming [mailto:address@hidden 
> Sent: Friday, January 30, 2009 10:52 AM
> To: Weddington, Eric
> Cc: Joerg Wunsch; address@hidden; address@hidden
> Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
> 
> On Friday 30 January 2009 18:21, Weddington, Eric wrote:
> 
> > > Here it is. I added some sed hocus-pocus to normalize the version
> > > numbers before comparisson. It is NOT bullit proof, but it handles
> > > one and/or two digit, possibly mixed, version numbers of 
> two and/or 
> > > three levels, possibly preceded by 'v' and augmented by release 
> > > denotifiers.
> > > 
> > 
> > Hmm.
> 
> 
> > First off, I'm moving this thread to the avr-libc-dev list 
> where it is more appropriate.
> This will be my last entry here (i am not yet receiving mail 
> for the other list)

Since you are an avr-libc developer (with commit privledges) you need to 
subscribe to the avr-libc-dev list.

 
> Please realize that this kind of approach is highly sensitive 
> to the way the version
> output is generated. It breaks if one word is added in the 
> string, or if version
> numbering is changed. 

The patch doesn't change that one way or the other. It's just as sensitive now, 
as it was before.

> Although arithmetic comparisons is 
> good, string comparison
> is not necessarily worse, provided the string is well 
> crafted, which is done by
> the 'sed magic' :-)

My eyes glaze over looking at those sed expressions. At least the arithmetic 
comparisons I can understand fairly quickly.

 
> Yes i realized that when after i submitted the patch. I 
> tested it on two linux distro's
> mac os and cygwin (and they run), but on a third distro it 
> turns out that the declaration
>   #! /bin/sh
> is not compatible with the function declaration, and should 
> be changed to
>  #!/bin/bash

What?! If that distro can't handle a little bit of whitespace, then I'd say 
that it's broken and doesn't deserve to be supported anyway.