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

2009-02-02 Thread Ruud Vlaming 
On Monday 02 February 2009 00:51, Timo Sandmann wrote:
 
 Am 01.02.2009 um 23:46 schrieb Ruud Vlaming:
  Users are supposed to download the official releases here:
  http://download.savannah.gnu.org/releases-noredirect/avr-libc/
  and use those. Then they don't need to bootstrap.
  Well i downloaded that file in my toolchainbuilder, and discovered
  it gives the error in the build process when you don't bootstrap,
  like this:
 
   cd avr-libc-1.6.4-build
   ../avr-libc-1.6.4/configure --prefix=$SOMEDIR --build=`../avr- 
  libc-1.6.4/config.guess` --host=avr
   make  make install
 
   config.status: error: cannot find input file: avr/lib/avr25/ 
  attiny13a/Makefile.in
 
 I guess you applied the patch 40-avr-libc-1.6.4-fix-attiny13a- 
 arch.patch? With this patch I need to use bootstrap (because the  
 patch moves the attiny13a from avr2 to avr25), without it the avr-libc  
 builds fine here without bootstrap.
I do. So the point is, when you apply a patch, then there is / may be
a need to bootstrap? Can this also hold true for other tools? I for
example never did so and experienced no problems until now.

 BTW: For me as a user it's even worse to build binutils with all the  
 patches from winavr, because AFAIK the autoconf / autoheader version  
 has to be exactly 2.59, not newer.
Can you be more specific? Is far as i know i apply all patches and did not
encounter this problem. From the present discussion you may have
understood that the version has to be 2.59=version=2.62. But that
point is addressed by a patch now (use mine or Eric's). What's the 
source of limitation?

Ruud


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-02 Thread Timo Sandmann 


Am 02.02.2009 um 14:24 schrieb Ruud Vlaming:

Insert the attached patch like this:
   other patches
  50-binutils-2.19-xmega.patch
  51-binutils-2.19-xmega2.patch
  52-1-xmega_sup.patch
  52-binutils-2.19-atmega32u6.patch


thanks! :-)

Timo



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-02 Thread Weddington, Eric 
 

 -Original Message-
 From: 
 avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
 org] On Behalf Of Ruud Vlaming
 Sent: Monday, February 02, 2009 6:24 AM
 To: Timo Sandmann
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 On Monday 02 February 2009 13:53, you wrote:
 
  When I applied the xmega-patches to binutils 2.19, the 
 build-process  
  failed:
  ../../binutils-2.19/bfd/elf32-avr.c: In function  
  'bfd_elf_avr_final_write_processing':
  ../../binutils-2.19/bfd/elf32-avr.c:1331: error: 
 'bfd_mach_avrxmega1'  
  undeclared (first use in this function)
 Insert the attached patch like this:
 other patches
50-binutils-2.19-xmega.patch
51-binutils-2.19-xmega2.patch
52-1-xmega_sup.patch
52-binutils-2.19-atmega32u6.patch
 
  My point was, that it would be easier for (non-windows) 
 users, if the  
  patches delivered with winavr would also contain the 
 makefile-updates,  
  so that's unnecessary to run automake / bootstrap to build 
 a toolchain  
  with the same patches as included in the winavr release.
 Indeed.
 

Thanks for the patch, Ruud! I'll see about including that.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-02 Thread Timo Sandmann 


Am 02.02.2009 um 01:28 schrieb Weddington, Eric:

BTW: For me as a user it's even worse to build binutils with all the
patches from winavr, because AFAIK the autoconf / autoheader version
has to be exactly 2.59, not newer.


I can't help that one. That requirement comes from the binutils folks.


Yes of course. But just as a feature request, it would be great to  
have additional patches for avr-libc, binutils and gcc doing these  
makefile-changes. Bootstrap / automake would then be unnecessary for  
users, who just want to build an up-to-date toolchain with the same  
patches that are included in the winavr-release.


Timo



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-02 Thread Ruud Vlaming 
On Monday 02 February 2009 13:53, you wrote:

 When I applied the xmega-patches to binutils 2.19, the build-process  
 failed:
 ../../binutils-2.19/bfd/elf32-avr.c: In function  
 'bfd_elf_avr_final_write_processing':
 ../../binutils-2.19/bfd/elf32-avr.c:1331: error: 'bfd_mach_avrxmega1'  
 undeclared (first use in this function)
Insert the attached patch like this:
    other patches
   50-binutils-2.19-xmega.patch
   51-binutils-2.19-xmega2.patch
   52-1-xmega_sup.patch
   52-binutils-2.19-atmega32u6.patch

 My point was, that it would be easier for (non-windows) users, if the  
 patches delivered with winavr would also contain the makefile-updates,  
 so that's unnecessary to run automake / bootstrap to build a toolchain  
 with the same patches as included in the winavr release.
Indeed.

Ruud
--- bfd/bfd-in2.h~  2007-08-06 21:59:15.0 +0200
+++ bfd/bfd-in2.h   2008-07-22 17:55:46.0 +0200
@@ -2017,6 +2017,13 @@
 #define bfd_mach_avr4  4
 #define bfd_mach_avr5  5
 #define bfd_mach_avr6  6
+#define bfd_mach_avrxmega1 101
+#define bfd_mach_avrxmega2 102
+#define bfd_mach_avrxmega3 103
+#define bfd_mach_avrxmega4 104
+#define bfd_mach_avrxmega5 105
+#define bfd_mach_avrxmega6 106
+#define bfd_mach_avrxmega7 107
   bfd_arch_bfin,/* ADI Blackfin */
 #define bfd_mach_bfin  1
   bfd_arch_cr16,   /* National Semiconductor CompactRISC (ie CR16). */
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-02 Thread Timo Sandmann 


Am 02.02.2009 um 09:33 schrieb Ruud Vlaming:

I guess you applied the patch 40-avr-libc-1.6.4-fix-attiny13a-
arch.patch? With this patch I need to use bootstrap (because the
patch moves the attiny13a from avr2 to avr25), without it the avr- 
libc

builds fine here without bootstrap.

I do. So the point is, when you apply a patch, then there is / may be
a need to bootstrap? Can this also hold true for other tools? I for
example never did so and experienced no problems until now.


If the applied patch needs a modified makefile, you have to update the  
makefile via bootstrap / automake or the patch itself has to contain  
these updates.



BTW: For me as a user it's even worse to build binutils with all the
patches from winavr, because AFAIK the autoconf / autoheader version
has to be exactly 2.59, not newer.
Can you be more specific? Is far as i know i apply all patches and  
did not

encounter this problem.


When I applied the xmega-patches to binutils 2.19, the build-process  
failed:
../../binutils-2.19/bfd/elf32-avr.c: In function  
'bfd_elf_avr_final_write_processing':
../../binutils-2.19/bfd/elf32-avr.c:1331: error: 'bfd_mach_avrxmega1'  
undeclared (first use in this function)


...

So I configured with --enable-maintainer-mode to run automake during  
the build-process. But that leads to:
configure.ac:26: error: Please use exactly Autoconf 2.59 instead of  
2.63.

config/override.m4:24: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:26: the top level
autom4te: /opt/local/bin/gm4 failed with exit status: 1
make: *** [../binutils-2.19/configure] Error 1

Using autoconf 2.59 instead of 2.63 solved that. AFAIK that's  
something binutils-specific.



From the present discussion you may have
understood that the version has to be 2.59=version=2.62. But that
point is addressed by a patch now (use mine or Eric's). What's the
source of limitation?


That's for the avr-libc bootstrap-script, but it's different for  
binutils (and not avr-specific).


My point was, that it would be easier for (non-windows) users, if the  
patches delivered with winavr would also contain the makefile-updates,  
so that's unnecessary to run automake / bootstrap to build a toolchain  
with the same patches as included in the winavr release.


Timo



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Anatoly Sokolov 
Hi.

 I'm ok with say that we require some verion = X. Anything  X should fail. 
 Anything = X should be allowed. With X being the lowest version that we 
 check for.

Test for autoconf min version alredy present in configure.ac:
38: AC_PREREQ(2.57)


Test for automake version can add this way:
configure.ac:126:
- AM_INIT_AUTOMAKE([dist-bzip2 no-dist-gzip])
+ AM_INIT_AUTOMAKE([1.8 dist-bzip2 no-dist-gzip])


And remove test for autoconf and automake min version from bootstrap.

Anatoly.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Weddington, Eric 
 

 -Original Message-
 From: Anatoly Sokolov [mailto:ae...@post.ru] 
 Sent: Sunday, February 01, 2009 9:02 AM
 To: Weddington, Eric; Ruud Vlaming
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 Hi.
 
  I'm ok with say that we require some verion = X. Anything 
  X should fail. Anything = X should be allowed. With X 
 being the lowest version that we check for.
 
 Test for autoconf min version alredy present in configure.ac:
 38: AC_PREREQ(2.57)
 
 
 Test for automake version can add this way:
 configure.ac:126:
 - AM_INIT_AUTOMAKE([dist-bzip2 no-dist-gzip])
 + AM_INIT_AUTOMAKE([1.8 dist-bzip2 no-dist-gzip])
 
 
 And remove test for autoconf and automake min version from bootstrap.
 

I like your idea. :-)

Even if the user has the wrong versions for the bootstrap script, it will be 
caught at the configuration step, and avr-libc won't be built anyway.

If there aren't any objections to this method, I'll volunteer to take care of 
making the changes.

Eric Weddington


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Ruud Vlaming 
On Sunday 01 February 2009 17:19, you wrote:
   I'm ok with say that we require some verion = X. Anything 
   X should fail. Anything = X should be allowed. With X 
  being the lowest version that we check for.
  
  Test for autoconf min version alredy present in configure.ac:
  38: AC_PREREQ(2.57)
  
  Test for automake version can add this way:
  configure.ac:126:
  - AM_INIT_AUTOMAKE([dist-bzip2 no-dist-gzip])
  + AM_INIT_AUTOMAKE([1.8 dist-bzip2 no-dist-gzip])
  
  And remove test for autoconf and automake min version from bootstrap.
 
 I like your idea. :-)
 Even if the user has the wrong versions for the bootstrap script, it will 
 be caught at the configuration step, and avr-libc won't be built anyway. 
Me too, that seems the way to go.

(To go one step further, would it not be possible to intergrate the steps the
bootstrap performs into configure?  We are back to the standard configure/make
procedure which everybody knows. I, for example, never bootstrapped before.)

 If there aren't any objections to this method, I'll volunteer to take care
 of making the changes. 
Please make it so.

Ruud


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Weddington, Eric 
 

 -Original Message-
 From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
 Sent: Sunday, February 01, 2009 9:47 AM
 To: Weddington, Eric; Joerg Wunsch; Anatoly Sokolov
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 (To go one step further, would it not be possible to 
 intergrate the steps the
 bootstrap performs into configure?  We are back to the 
 standard configure/make
 procedure which everybody knows. I, for example, never 
 bootstrapped before.)
 

If you look at the top of the bootstrap script, you'll see a comment as to why 
the bootstrap script is needed:
# bootstrap script to build all the *.in files and configure script.

When avr-libc is released, the configure script is pre-built and distributed in 
the release. The bootstrap script is required for avr-libc *developers*, who 
may change the *.in, or *.ac files and then rebuild the configure script.

Eric Weddington


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Ruud Vlaming 
On Sunday 01 February 2009 18:53, Weddington, Eric wrote:
 
  -Original Message-
  From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
  Sent: Sunday, February 01, 2009 9:47 AM
  To: Weddington, Eric; Joerg Wunsch; Anatoly Sokolov
  Cc: avr-gcc-list@nongnu.org
  Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
  
  (To go one step further, would it not be possible to 
  intergrate the steps the
  bootstrap performs into configure?  We are back to the 
  standard configure/make
  procedure which everybody knows. I, for example, never 
  bootstrapped before.)
  
 
 If you look at the top of the bootstrap script, you'll see a comment as to 
 why the bootstrap script is needed: # bootstrap script to build all the 
 *.in files and configure script. 
 
 When avr-libc is released, the configure script is pre-built and distributed 
 in the release. The bootstrap script is required for avr-libc *developers*, 
 who may change the *.in, or *.ac files and then rebuild the configure script. 
  

Yes, i read why it is needed, and for lib-c developers that is not a problem.
For users however, that just want to build the libc and move on it would be
better if it wouldn't (or was integrated in one script somehow)

So now we are again at the reason why i placed the first post of this
discussion. If you do not bootstrap, you miss one file. This issue was not
pressent on earlier versions, i never needed to bootstrap just to build.

Ruud


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Weddington, Eric 
 

 -Original Message-
 From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
 Sent: Sunday, February 01, 2009 2:36 PM
 To: Weddington, Eric
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 Yes, i read why it is needed, and for lib-c developers that 
 is not a problem.
 For users however, that just want to build the libc and move 
 on it would be
 better if it wouldn't (or was integrated in one script somehow)
 

Users are supposed to download the official releases here:
http://download.savannah.gnu.org/releases-noredirect/avr-libc/
and use those. Then they don't need to bootstrap.

If you are building from CVS, then you need to use bootstrap.

This is nothing new, and it is very common to do in other projects, like the 
GNU projects. For example GCC.

Eric Weddington


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Ruud Vlaming 
On Sunday 01 February 2009 23:25, you wrote:
 
  -Original Message-
  From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
  Sent: Sunday, February 01, 2009 2:36 PM
  To: Weddington, Eric
  Cc: avr-gcc-list@nongnu.org
  Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
  
  Yes, i read why it is needed, and for lib-c developers that 
  is not a problem.
  For users however, that just want to build the libc and move 
  on it would be
  better if it wouldn't (or was integrated in one script somehow)
  
 
 Users are supposed to download the official releases here:
 http://download.savannah.gnu.org/releases-noredirect/avr-libc/
 and use those. Then they don't need to bootstrap.
Well i downloaded that file in my toolchainbuilder, and discovered
it gives the error in the build process when you don't bootstrap,
like this:

  cd avr-libc-1.6.4-build
  ../avr-libc-1.6.4/configure --prefix=$SOMEDIR 
--build=`../avr-libc-1.6.4/config.guess` --host=avr
  make  make install

  config.status: error: cannot find input file: 
avr/lib/avr25/attiny13a/Makefile.in

If you do bootstrap you do not get this error, as you and Timo explained.

 If you are building from CVS, then you need to use bootstrap.
 This is nothing new, and it is very common to do in other projects, 
 like the GNU projects. For example GCC. 
Clear.

So probably i did not expres myself clearly. I think i understand the 
procedures,
but as it is right now, users have to bootstrap otherwise they experience the
bug i encountered. Developers do not notice it, since it is 'cured' by 
bootstrapping.
I only encountered it because my toolchainbuilder is not for developers, but for
users.

So i am crazy or is there indeed something that needs to be corrected?

Ruud


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Weddington, Eric 
 

 -Original Message-
 From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
 Sent: Sunday, February 01, 2009 3:47 PM
 To: Weddington, Eric
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 So i am crazy or is there indeed something that needs to be corrected?
 

Hmm. You might be right.

Joerg, can you comment on this? Users of the release are not supposed to have 
to bootstrap, correct? That's the way that it is described in the docs:
http://www.nongnu.org/avr-libc/user-manual/install_tools.html

I just noticed that in my build script I always do the bootstrap step.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Timo Sandmann 


Am 01.02.2009 um 23:46 schrieb Ruud Vlaming:

Users are supposed to download the official releases here:
http://download.savannah.gnu.org/releases-noredirect/avr-libc/
and use those. Then they don't need to bootstrap.

Well i downloaded that file in my toolchainbuilder, and discovered
it gives the error in the build process when you don't bootstrap,
like this:

 cd avr-libc-1.6.4-build
 ../avr-libc-1.6.4/configure --prefix=$SOMEDIR --build=`../avr- 
libc-1.6.4/config.guess` --host=avr

 make  make install

 config.status: error: cannot find input file: avr/lib/avr25/ 
attiny13a/Makefile.in


I guess you applied the patch 40-avr-libc-1.6.4-fix-attiny13a- 
arch.patch? With this patch I need to use bootstrap (because the  
patch moves the attiny13a from avr2 to avr25), without it the avr-libc  
builds fine here without bootstrap.



snip


So probably i did not expres myself clearly. I think i understand  
the procedures,
but as it is right now, users have to bootstrap otherwise they  
experience the

bug i encountered.


IMHO the point is that users need to bootstrap, if they apply a patch  
which needs changes in a makefile.
BTW: For me as a user it's even worse to build binutils with all the  
patches from winavr, because AFAIK the autoconf / autoheader version  
has to be exactly 2.59, not newer.


Timo



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-02-01 Thread Weddington, Eric 
 

 -Original Message-
 From: Timo Sandmann [mailto:m...@timosandmann.de] 
 Sent: Sunday, February 01, 2009 4:51 PM
 To: Ruud Vlaming
 Cc: Weddington, Eric; avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 
 Am 01.02.2009 um 23:46 schrieb Ruud Vlaming:
  Users are supposed to download the official releases here:
  http://download.savannah.gnu.org/releases-noredirect/avr-libc/
  and use those. Then they don't need to bootstrap.
  Well i downloaded that file in my toolchainbuilder, and discovered
  it gives the error in the build process when you don't bootstrap,
  like this:
 
   cd avr-libc-1.6.4-build
   ../avr-libc-1.6.4/configure --prefix=$SOMEDIR --build=`../avr- 
  libc-1.6.4/config.guess` --host=avr
   make  make install
 
   config.status: error: cannot find input file: avr/lib/avr25/ 
  attiny13a/Makefile.in
 
 I guess you applied the patch 40-avr-libc-1.6.4-fix-attiny13a- 
 arch.patch? 

Oh, duh, of course that's why I bootstrap. (Sorry, it's been a long day for me.)


 
 BTW: For me as a user it's even worse to build binutils with all the  
 patches from winavr, because AFAIK the autoconf / autoheader version  
 has to be exactly 2.59, not newer.

I can't help that one. That requirement comes from the binutils folks.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Ruud Vlaming 
On Thursday 29 January 2009 17:28, you wrote:
  If you agree with me that a simple version comparison with a
  two digit number, emmiting a warning only is sufficient in this
  case i can make the patch.
 
 I'm ok with say that we require some verion = X. Anything  X 
 should fail. Anything = X should be allowed. With X being the
 lowest version that we check for.  

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.

Ruud.
--- bootstrap	2008-09-19 15:43:17.0 +0200
+++ bootstrap	2009-01-30 10:01:26.0 +0100
@@ -5,37 +5,53 @@
 # bootstrap script to build all the *.in files and configure script.
 #
 
-# autoconf-2.59, 2.60, 2.61, or 2.62 is required
+function version()
+{ # Simple version normalizer by Ruud Vlaming (r...@betaresearch.nl)
+  echo $1 | sed -e 's/$/ /' -e 's/^/ /' \
+-e 's/^.*[v ]\([0-9]\)\.\([0-9].*\)$/ 0\1.\2 /' \
+-e 's/^.*[v ]\([0-9][0-9]*\.[0-9][0-9]*\)[- ].*$/ \1 /' \
+-e 's/^.*[v ]\([0-9][0-9]*\)\.\([0-9]\)[- ].*$/ \1.0\2/' \
+-e 's/^.*[v ]\([0-9][0-9]*\.[0-9\.]*\).*$/ \1/' \
+-e 's/^.*[v ]\([0-9][0-9]*\)\.\([0-9]\)\.\(.*\)$/ \1.0\2\.\3/' \
+-e 's/^.*[v ]\([0-9][0-9]*\)\.\([0-9]*\)\.\([0-9]\)\.*$/ \1.\2\.0\3/'
+}
+
+# at least autoconf-2.59 is required
 
 : ${AUTOHEADER=autoheader${AC_VER}}
 : ${AUTOCONF=autoconf${AC_VER}}
 
-# automake-1.8.x, 1.9.x, or 1.10.x is required
+# at least automake-1.8.x, is required
 
 : ${ACLOCAL=aclocal${AM_VER}}
 : ${AUTOMAKE=automake${AM_VER}}
 
 # Verify autoconf version
 
-AUTOCONF_VER=`(${AUTOCONF} --version 2/dev/null | head -n 1 | \
-  cut -d ' ' -f 4) 2/dev/null`
-if [ $AUTOCONF_VER != 2.59 -a $AUTOCONF_VER != 2.60 -a $AUTOCONF_VER != 2.61 \
- -a $AUTOCONF_VER != 2.62 ]
+AUTOCONF_VER=`(${AUTOCONF} --version | head -n 1 2/dev/null)`
+AUTOCONF_MIN=2.59
+AUTOCONF_TST=`version $AUTOCONF_VER`
+AUTOCONF_CMP=`version $AUTOCONF_MIN`
+
+if [ $AUTOCONF_TST \ $AUTOCONF_CMP ]
 then
-	echo You need to use autoconf version 2.59, 2.60, 2.61, or 2.62.
-	echo You are using `${AUTOCONF} --version | head -n 1`.
+	echo You need to use autoconf version = $AUTOCONF_MIN 
+echo You are using $AUTOCONF_VER.
 	exit 1
 fi
 
 # Verify automake version
 
-AUTOMAKE_VER=`(${AUTOMAKE} --version | head -n 1 | \
-  cut -d ' ' -f 4 | cut -d '.' -f -2) 2/dev/null`
-if [ $AUTOMAKE_VER != 1.8 -a $AUTOMAKE_VER != 1.9 -a $AUTOMAKE_VER != 1.10 ]
+AUTOMAKE_VER=`(${AUTOMAKE} --version | head -n 1 2/dev/null)`
+AUTOMAKE_MIN=1.8
+AUTOMAKE_TST=`version $AUTOMAKE_VER`
+AUTOMAKE_CMP=`version $AUTOMAKE_MIN`
+
+if [ $AUTOMAKE_TST \ $AUTOMAKE_CMP ]
 then
-	echo You need to use automake version 1.8, 1.9, or 1.10.
-	echo You are using `${AUTOMAKE} --version | head -n 1`.
-	exit 1
+echo You need to use automake version = $AUTOMAKE_MIN 
+echo You are using $AUTOMAKE_VER.
+exit 1
 fi
 
 AUTOMAKE=${AUTOMAKE} --foreign --add-missing --copy
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Weddington, Eric 
 

 -Original Message-
 From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
 Sent: Friday, January 30, 2009 5:43 AM
 To: Weddington, Eric
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 On Thursday 29 January 2009 17:28, you wrote:
   If you agree with me that a simple version comparison with a
   two digit number, emmiting a warning only is sufficient in this
   case i can make the patch.
  
  I'm ok with say that we require some verion = X. Anything  X 
  should fail. Anything = X should be allowed. With X being the
  lowest version that we check for.  
 
 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.

Second, see an alternative patch that is attached. This is against the 1.6 
branch.

It's only had minimal testing. But it avoids the complicated sed magic, and 
string comparison, by instead doing arithmetic expansion on the major and minor 
parts of the version string and then doing arithmetic comparisons. That way we 
can check if the major parts are equal and the minor part of the revision is 
less than some specific value, then abort because the version does not meet the 
minimal requirement.

Thoughts?

Joerg, how well would this work on FreeBSD? These changes are only bash-isms 
AFAIK, but you know more about unix compatibility issues.

Eric Weddington


bootstrap.patch
Description: bootstrap.patch
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Ruud Vlaming 
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)

 Second, see an alternative patch that is attached. This is against the 1.6 
 branch.
Thats fine with me too.
 
 It's only had minimal testing. But it avoids the complicated sed magic, 
 and string comparison, by instead doing arithmetic expansion on the 
 major and minor parts of the version string and then doing arithmetic
 comparisons. That way we can check if the major parts are equal and the minor
 part of the revision is less than some specific value, then abort because the
 version does not meet the minimal requirement. 
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. Although arithmetic comparisons is good, string comparison
is not necessarily worse, provided the string is well crafted, which is done by
the 'sed magic' :-)

 Joerg, how well would this work on FreeBSD? These changes are only bash-isms 
 AFAIK, but you know more about unix compatibility issues. 
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
I dunno about Free BSD

Ruud


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Weddington, Eric 
 

 -Original Message-
 From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
 Sent: Friday, January 30, 2009 10:52 AM
 To: Weddington, Eric
 Cc: Joerg Wunsch; avr-gcc-list@nongnu.org; avr-libc-...@nongnu.org
 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.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread 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


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Weddington, Eric 
 

 -Original Message-
 From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
 Sent: Friday, January 30, 2009 11:38 AM
 To: Weddington, Eric
 Cc: avr-gcc-list@nongnu.org; avr-libc-...@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
  
  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 ...;-)

LOL!
 
   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. 

Somehow I just *knew* you were going to say that... :-)

 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.

I'd like to say that bootstrap is a bash script. But if all it takes to get it 
working on sh is to remove the space then I suppose that's ok, as long as it 
doesn't screw up anything else.
 
 Anyway we should take the patch that has the broadest scoop.
 Thats probably yours. I will test it asap.

Thanks,
Eric Weddington


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Preston Wilson 

 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.
 
 Somehow I just *knew* you were going to say that... :-)
 
 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.

The problem is that Ubuntu (by default) links sh to dash, and almost all
other Linux distributions link sh to bash.  [sh is bash under Cygwin too.]
I have not kept up with the state of the various command interpreters, but I
suspect that bash is a superset of the POSIX standard for sh, and that the
script is using something that is specific to bash.  It could also be that
dash has not implemented some POSIX feature, but my guess is that is less
likely the case.

Two solutions: replace the bash specific feature with something that will
work under a strictly POSIX shell (or lesser enabled POSIX shell), or use
#! /bin/bash as the interpreter instead of #! /bin/sh.  As Rudd states,
the space is not the issue.

-Preston




___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Weddington, Eric 
 

 -Original Message-
 From: Preston Wilson [mailto:pwil...@scopuli.com] 
 Sent: Friday, January 30, 2009 12:38 PM
 To: Weddington, Eric; Ruud Vlaming
 Cc: avr-gcc-list; avr-libc-...@nongnu.org
 Subject: Re: [avr-libc-dev] RE: [avr-gcc-list] no 
 avr/lib/avr25/attiny13a/Makefile.in
 
 
 Two solutions: replace the bash specific feature with 
 something that will
 work under a strictly POSIX shell (or lesser enabled POSIX 
 shell), or use
 #! /bin/bash as the interpreter instead of #! /bin/sh.  

I'm ok with this, however, I think that Joerg should approve that particular 
change; I don't know the effects of this for any of the *BSDs, or Solaris. 
Avr-libc is built on so many different platforms these days.

Eric


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Vincent Trouilliez 
 The problem is that Ubuntu (by default) links sh to dash, and almost all
 other Linux distributions link sh to bash.

Not that Ubuntu needs anyone to jump in to defend them but ;-)
as an Ubuntu user since day one, I do vividly remember when they
thoughtfully decided, nearly 3 years ago, to replace bash
with dash. So, it's indeed an Ubuntu thing. I even found the old
spec in their wiki about this change:

https://wiki.ubuntu.com/DashAsBinSh/Spec

However I can't see how they could be blamed for this change:

1) Dash executes scripts much faster, that's why they decided to
switch to it, mainly to help improve boot times, which really needed it
back then.
2) It's POSIX compliant.
3) Dash is only used for executing scripts anyway, bash is conserved for
the user shell.

 ...and that the script is using something that is specific to bash.

So one can hardly blame Ubuntu...


--
Vince, bullet proof jacket on.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Joerg Wunsch 
OK, a mass reply as so many articles arrived on that thread.

As Weddington, Eric wrote:

 Joerg, how well would this work on FreeBSD? These changes are only
 bash-isms AFAIK, but you know more about unix compatibility issues.

Your patch is completely free of any bashism, so it's fine.

Ruud's original patch contains just one thing that is not generally
applicable (at least from glancing at it -- I didn't try it): the
keyword function (actually a kshism, to be fair).  Just remove that
keyword, and you're fine -- seriously, I never understood why Dave
Korn introduced that keyword at all.  Shell functions have been in use
long before the Korn shell (so they are also available in the
non-Posix Solaris /bin/sh), but without the need of any keyword to
introduce them.  Just writing

version()
{
   # body of function
}

does the trick.

The only other cosmetic thing I'd like to change is this comment:

# Simple version normalizer by Ruud Vlaming (r...@betaresearch.nl)

IMHO that's a meta information that rather belongs into the CVS commit
message (and into the ChangeLog file then).


As Weddington, Eric wrote:

 Bah. Attachment error. Trying again.

Your mailer sends application/octet-stream attachments that are
stripped by the mailing list software.  Try renaming the patch into
something that ends in .txt, I guess that will make your MUA declare
it as text/plain.


As Ruud Vlaming wrote:

   #! /bin/sh
 is not compatible with the function declaration, and should be changed to
  #!/bin/bash
 I dunno about Free BSD

Better just stick with that dash shell, which appears to be a
version of the Almquist shell.  This is essentially the same shell as
the one that is used by the 4.4BSD derivatives, and it aims to be a
minimal Posix shell, without ending up in creeping featurism as bash
does.

However, note that Solaris (alas) doesn't ship with a Posix compliant
/bin/sh by default.  The Solaris shell lacks:

. the more esoteric #, ##, %, and %% variable expansion modifiers,
  use sed or expr instead, and

. shell arithmetics, use expr instead.

One of the auto* tools (I think it's autoconf) contains a good
collection of hints for writing portable shell scripts.

/bin/bash is completely unportable, and will most likely only work on
Linux systems.  (Other systems, even if they offer a bash as an
alternative shell, might offer it as /usr/bin/bash or even
/usr/local/bin/bash.)  /bin/sh is essentiall the only agreed standard
name of a shell, but for a Posix-sanctioned way, you'd have to use
just a colon as the first line rather than the sheebang (#!) magic.


As Weddington, Eric wrote:

#! /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.

It's not the white space but the different name of the shell.

OT: Ted Roth once mentioned to me that he's always using the
whitespaced version of the sheebang magic:

#! /name of interpreter

rather than

#!/name of interpreter

The reason for that is that there used to be one historical version of
Unix that simply interpreted the first four characters #! / as a
32-bit magic number to decide this is to be handled as an
interpreted script rather than a native executable.  For any modern
Unix-like system, it doesn't really matter.


As Ruud Vlaming wrote:

  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 ...;-)

I know it as Regular expressions are always write-only items.


As Preston Wilson wrote:

 I have not kept up with the state of the various command
 interpreters, but I suspect that bash is a superset of the POSIX
 standard for sh, and that the script is using something that is
 specific to bash.

Yep, exactly.

-- 
cheers, Jorg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-30 Thread Weddington, Eric 
 

 -Original Message-
 From: 
 avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
 org] On Behalf Of Joerg Wunsch
 Sent: Friday, January 30, 2009 2:01 PM
 To: avr-gcc-list@nongnu.org
 Cc: r...@betaresearch.nl
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 However, note that Solaris (alas) doesn't ship with a Posix compliant
 /bin/sh by default.  The Solaris shell lacks:
 
 . the more esoteric #, ##, %, and %% variable expansion modifiers,
   use sed or expr instead, and
 
 . shell arithmetics, use expr instead.
 

Ok, I'm not a Unix guy. What do you mean by the last statement above? Does this 
mean that my solution won't work on Solaris?


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-29 Thread Ruud Vlaming 
On Thursday 29 January 2009 05:54, you wrote:

 Yes, the version checking in the bootstrap script is 
 quite stupid. Right now it looks for specific versions only.
 It would be ideal if we could look for a range.  
 
  The question is: is this really needed? Can the
  script not simply issue a warning and go on?
 
 I'm certainly open to changing it. Can you provide a patch?

Yes, but first we have to decide, what should the patch do?
Imho that patch should not block execution at all, only warn
for a possile mismatch of version numbers.

The point is, until we have a firm spec how all applications
should emit their version nummers over de command line,
there will not be a stable solution for version number 
comparison. 

I have written a script which does a reasonable job for in most
situations for version numbers up to three level version numbers.
However, this is quite lengthy, and still is not bullitproof.
I think this is not adequate for this situation.

If you agree with me that a simple version comparison with a
two digit number, emmiting a warning only is sufficient in this
case i can make the patch.

Ruud


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-29 Thread Weddington, Eric 
 

 -Original Message-
 From: Ruud Vlaming [mailto:r...@betaresearch.nl] 
 Sent: Thursday, January 29, 2009 8:39 AM
 To: Weddington, Eric
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 On Thursday 29 January 2009 05:54, you wrote:
 
  Yes, the version checking in the bootstrap script is 
  quite stupid. Right now it looks for specific versions only.
  It would be ideal if we could look for a range.  
  
   The question is: is this really needed? Can the
   script not simply issue a warning and go on?
  
  I'm certainly open to changing it. Can you provide a patch?
 
 Yes, but first we have to decide, what should the patch do?
 Imho that patch should not block execution at all, only warn
 for a possile mismatch of version numbers.
 
 The point is, until we have a firm spec how all applications
 should emit their version nummers over de command line,
 there will not be a stable solution for version number 
 comparison. 
 
 I have written a script which does a reasonable job for in most
 situations for version numbers up to three level version numbers.
 However, this is quite lengthy, and still is not bullitproof.
 I think this is not adequate for this situation.
 
 If you agree with me that a simple version comparison with a
 two digit number, emmiting a warning only is sufficient in this
 case i can make the patch.

I'm ok with say that we require some verion = X. Anything  X should fail. 
Anything = X should be allowed. With X being the lowest version that we check 
for.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-29 Thread Steven Michalske 


On Jan 29, 2009, at 8:28 AM, Weddington, Eric wrote:





-Original Message-
From: Ruud Vlaming [mailto:r...@betaresearch.nl]
Sent: Thursday, January 29, 2009 8:39 AM
To: Weddington, Eric
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Thursday 29 January 2009 05:54, you wrote:


Yes, the version checking in the bootstrap script is
quite stupid. Right now it looks for specific versions only.
It would be ideal if we could look for a range.


The question is: is this really needed? Can the
script not simply issue a warning and go on?


I'm certainly open to changing it. Can you provide a patch?


Yes, but first we have to decide, what should the patch do?
Imho that patch should not block execution at all, only warn
for a possile mismatch of version numbers.

The point is, until we have a firm spec how all applications
should emit their version nummers over de command line,
there will not be a stable solution for version number
comparison.

I have written a script which does a reasonable job for in most
situations for version numbers up to three level version numbers.
However, this is quite lengthy, and still is not bullitproof.
I think this is not adequate for this situation.

If you agree with me that a simple version comparison with a
two digit number, emmiting a warning only is sufficient in this
case i can make the patch.


I'm ok with say that we require some verion = X. Anything  X  
should fail. Anything = X should be allowed. With X being the  
lowest version that we check for.




When defining what version work,

i like

minimum, maximum and excluded  as the options  but they are three  
seperate tests


normally you use the minimum,  if a feature you required is now  
excluded/deprecated you add the max

if a version is known bad you exclude.

Hardkrash



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-29 Thread Weddington, Eric 
 

 -Original Message-
 From: 
 avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
 org] On Behalf Of Steven Michalske
 Sent: Thursday, January 29, 2009 2:03 PM
 To: avr-gcc List
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 When defining what version work,
 
 i like
 
 minimum, maximum and excluded  as the options  but they are three  
 seperate tests
 
 normally you use the minimum,  if a feature you required is now  
 excluded/deprecated you add the max
 if a version is known bad you exclude.
 

Patches welcome.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-28 Thread Ruud Vlaming 
On Tuesday 27 January 2009 01:19, Timo Sandmann wrote:
 Am 26.01.2009 um 23:50 schrieb Ruud Vlaming:
  config.status: error: cannot find input file: avr/lib/avr25/ 
  attiny13a/Makefile.in
 I used the bootstrap-script to let automake generate the missing  
 Makefile.in.

Hey, i never used that, I thought it was not needed, it is not in the
readme, and i recall i read once somewhere that it was only needed
van using cvs.

Anyway, it does the trick, sort of.

Thanks for the tip.

Ruud.



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-28 Thread Weddington, Eric 
 

 -Original Message-
 From: 
 avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
 org] On Behalf Of Ruud Vlaming
 Sent: Wednesday, January 28, 2009 3:28 PM
 To: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 On Tuesday 27 January 2009 01:25, you wrote:
 
  Oh, of course, I do that too. Thanks for mentioning that.
 
 Things that have been automated have a tendency to be forgotten.
 However, that is not always wise, for the bootstrap script seems
 to have a flaw i think. It checks for the version numbers 
  2.59, 2.60, 2.61, or 2.62
 In the meantime i have version 2.63 and i think that works
 well also. The version number checking should allow for
 higher versions too. 

Yes, the version checking in the bootstrap script is quite stupid. Right now it 
looks for specific versions only. It would be ideal if we could look for a 
range.

 The question is: is this really needed? Can the
 script not simply issue a warning and go on?

I'm certainly open to changing it. Can you provide a patch?

Eric


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-26 Thread Timo Sandmann 


Am 26.01.2009 um 23:50 schrieb Ruud Vlaming:

Hi,

I don't think it was mentioned here yet, so please know that,
when you try to build avr-libc-1.6.4 with the patches,
30-avr-libc-1.6.4-dwarf2.patch
31-avr-libc-1.6.4-builtins.patch
40-avr-libc-1.6.4-fix-attiny13a-arch.patch
applying the last patch results in an error when building

 cd avr-libc-1.6.4-build
 ../avr-libc-1.6.4/configure --prefix=$SOMEDIR --build=`../avr- 
libc-1.6.4/config.guess` --host=avr

 make  make install

config.status: error: cannot find input file: avr/lib/avr25/ 
attiny13a/Makefile.in


Indeed, that file is not present. So the only option seems to leave  
that

last patch out (in which case the build succeeds).
Or should one take an other action?

Ruud


Hi Ruud,

I used the bootstrap-script to let automake generate the missing  
Makefile.in.


Timo


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

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

2009-01-26 Thread Weddington, Eric 
 

 -Original Message-
 From: 
 avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
 org] On Behalf Of Timo Sandmann
 Sent: Monday, January 26, 2009 5:19 PM
 To: Ruud Vlaming
 Cc: avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
 
 
 Am 26.01.2009 um 23:50 schrieb Ruud Vlaming:
  Hi,
 
  I don't think it was mentioned here yet, so please know that,
  when you try to build avr-libc-1.6.4 with the patches,
  30-avr-libc-1.6.4-dwarf2.patch
  31-avr-libc-1.6.4-builtins.patch
  40-avr-libc-1.6.4-fix-attiny13a-arch.patch
  applying the last patch results in an error when building
 
   cd avr-libc-1.6.4-build
   ../avr-libc-1.6.4/configure --prefix=$SOMEDIR --build=`../avr- 
  libc-1.6.4/config.guess` --host=avr
   make  make install
 
  config.status: error: cannot find input file: avr/lib/avr25/ 
  attiny13a/Makefile.in
 
  Indeed, that file is not present. So the only option seems 
 to leave  
  that
  last patch out (in which case the build succeeds).
  Or should one take an other action?
 
  Ruud
 
 Hi Ruud,
 
 I used the bootstrap-script to let automake generate the missing  
 Makefile.in.
 

Oh, of course, I do that too. Thanks for mentioning that.


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list