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

[Ruud Vlaming]

On Friday 30 January 2009 19:08, Weddington, Eric wrote:
> Since you are an avr-libc developer (with commit privledges) 
> you need to subscribe to the avr-libc-dev list. 
I did, but somewhere in the line it takes time. 

> > 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. 
Yes, but my implementation could be more stable in the future.
On the other hand, thit patch will then probably not be needed
any more, so this is not a big point.

> > 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. 
It is a matter of taste i guess, but for most it is certainly a WORN 
language: write once, read never ...;-)

> > 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. 
Now be carefull, this is ubuntu. But the white space is not the issue
here, but the difference between 'sh' and 'bash' and to what that
is mapped in the distro i guess. On my gentoo machines there is no
problem what so ever.

Anyway we should take the patch that has the broadest scoop.
Thats probably yours. I will test it asap.

Ruud