Re: How to use pgmspace.h in a library source without warning?

Weddington, Eric schrieb:
> 
>> -----Original Message----- From: Georg-Johann Lay 
>> [mailto:[email protected]] Sent: Saturday, June 08, 2013 6:36 AM To: 
>> Weddington, Eric Cc: Thomas D. Dean; [email protected] 
>> Subject: Re: [avr-gcc-list] How to use pgmspace.h in a library 
>> source without warning?
>> 
>> Weddington, Eric wrote:
>> 
>>> computers get faster every year
>> Computers don't get faster.
>> 
>> It's just the case that the not-so-fast computers are declared as 
>> scrap, and thrown away an then replaced by a-bit-faster computers; 
>> again and again and again...
> 
> Pedantically, yes. That's what I was referring to.
> 
>> I don't think that things should get more complicated and more 
>> resource gulping -- in the contrary: things should get easier to 
>> grasp and to handle and to understand.
>> 
> 
> In a way, lib/device would actually be simpler then lib/arch. When a 
> user compiles a program, they compile it for a specific device, not 
> an architecture. Then the library for the architecture gets linked 
> in.
> 
> The only thing that I see that gets complicated is transitioning from
>  one style to the other, and then the increase in compilation.

Just perform the following 2 steps:

1) Make AVR-LibC adopt avr-gcc's multilib layout.
    Currently, we have

$ avr-gcc -print-multi-lib
.;
avr25;@mmcu=avr25
avr3;@mmcu=avr3
avr31;@mmcu=avr31
avr35;@mmcu=avr35
avr4;@mmcu=avr4
avr5;@mmcu=avr5
avr51;@mmcu=avr51
avr6;@mmcu=avr6
avrxmega2;@mmcu=avrxmega2
avrxmega4;@mmcu=avrxmega4
avrxmega5;@mmcu=avrxmega5
avrxmega6;@mmcu=avrxmega6
avrxmega7;@mmcu=avrxmega7
tiny-stack;@msp8
avr25/tiny-stack;@mmcu=avr25@msp8

2) Change avr-gcc's multilib layout to whatever you want.
    Notice that this fixes #35407 (add tiny-stack multilibs).

> Again, I see it being offset by being able to build on newer, faster 
> computers and by building in parallel. Will it be completely offset? 
> No, of course not. But then we can really design libraries to be 
> specific to devices and get rid of some of the kludges and 
> compromises that are in there in building it per arch.

we just had the request to (effectively) raise -Os to a multilib option. 
  That way the libraries can be tailored for small code or for fast code.

And there was the request to raise -f[no-]short-double to a multilib 
option so that double can be 32 or 64 bits wide.

That would flood us with ~800 multilibs. Arrgh.

Johann