Re: [avr-libc-dev] build per arch

[Joerg Wunsch]

As Theodore A. Roth wrote:

> or maybe like this:
> 
>   ./avr5/atmega128/libc.a
>   ./avr5/atmega128/libm.a
>   ./avr5/atmega128/libprintf_min.a
>   ./avr5/atmega128/libprintf_flt.a
>   ./avr5/atmega128/libscanf_min.a
>   ./avr5/atmega128/libscanf_flt.a
>   ./avr5/atmega128/crtm128.o

Now, that gets me an idea.

What about sticking to the `arch' model in general but allowing for a
kind of per-MCU override?

So the layout (dirs only) could look like

./avr2
./avr3
./avr4
./avr5
./avr5/atmega169
./avr5/at90can128

The compiler passes both, the -mavrN plus the -mmcu= option to the
linker, and if the linker finds a subdir that is more specific, it can
use that one, otherwise it resorts to the per-arch subdir.

That has the added benefit that the binutils (ld) change could be
decoupled from the respective GCC change: if an old compiler works
against a new ld, it'll just pass the -mavrN option only, and the
linker will behave as it used to do by now.  Only the new compiler
requires the updated ld (since the old one would not understand the
-mmcu option).

avr-ld -mfoo says:

avr-ld: unrecognised emulation mode: foo
Supported emulations: avr85xx avr1200 avr23xx avr44x4 avr4433 avrmega603 
avrmega103 avrmega161 avr1 avr2 avr3 avr4 avr5

Hmm, time to drop the ancient avr85xx ... avrmega161 options, too. ;-)

> Of course, this will cause the build to take a considerly long time, but
> who cares, we've all got 3 GHz systems by now, right? 8-)

I've always got the impression that 2/3 of the overall compilation
time are taken by the two runs of doxygen (plus two LaTeX runs)
anyway.  Well, and by sending the output to the tty :) (can seriously
increase your compile time if the output goes across a slow line).
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/