> > I against, to build full the avr-libc library for device, > > this dramatically > > increase compile time and the code size of avr-libc. Instead, > > I suggest to > > build libc for architecture and add small library with device specific > > functions for eeprom, wdt, boot e.t.c. modules.
Hmm... Yes, this is better in compile time and library image size in comparison to pure lib_per_device. However, this excludes the possible optimization, for example '-mtiny-stack' for ATtiny2313. At the other hand, the current lib_per_arch approach permits to have a small set functions per device with CPP redefining. In practice, it would be good to use lib_per_project approach, where the user builds the library individually for each separate project. The user adds the compiler switches and library components choices. The advantages are: - optimization tuning, for example '-mcall-prologues' is not always the best choice, - extra optimization choice, for example OPTIMIZE_SPEED in a few of string functions, - no magic link switches like 'printf_flt', as this is resolved at compile-time, - extra variants, which are not suitable as universal, for example, to abort the program in case of interrupt vector is not set, or to place the code into unused interrupt zone. This approach is used, for example, in eCos RTOS. Personaly, I have compile my own libraries separatly in each project. However, I have no ideas how to make this in binary WinAVR distributive. Regards, Dmitry. _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
