Re: [avr-gcc-list] Makefile Procyon AVRlib vs AVR-libc and ANSI C

[Joerg Wunsch]

Patrick Blanchard <address@hidden> wrote:

> 2. I am attempting to merge pstang's AVRlib with the makefile from
> AVR-libc. What and how is the best way to proceed in your opinion?

The Makefile template that ships in avr-libc's demo project is just a
simple suggestion.  Everything else should work as well.  WinAVR has
its only Makefile template which simply evolved over time based on
feedback from WinAVR users (I believe).

> 3. Why is AVR-libc not ANSI C as far as declarations? This is a
> confusing issue. Declarations appear to be asm centric, and not ANSI
> C centric.

Can you elaborate?  I don't see what you mean.  avr-libc aims to
implement as much of ISO/IEC 9899:1990 (``ANSI-C'') as makes sense,
and few things from ISO/IEC 9899:1999 as they fit nicely into the
scheme (like stdint.h, but unlike wide character support, just to
mention a couple of examples).

> #compiler flags
>         CPFLAGS = -g  -Os -Wall -Wstrict-prototypes -I$(AVRLIB) -Wa,-
> ahlms=$(<:.c=.lst)

I'd construct them using several macros, that helps to distinguish
different features (like optimization settings, debugging format,
include path lists, etc. -- COPT, CDEBUG, CINCS).  Also, the final
list of flags to pass to the C compiler has the conventional name
"CFLAGS".  Of course, it's just a convention and nothing would ever
enforce that, but violating conventions without a good reason always
bears the risk of confusing people who just have a glance at the
stuff.  POLA -- principle of least astonishment.

> #linker flags
>         LDFLAGS = -Wl,-Map=$(TRG).map,--cref

Btw., I personally don't think linker maps make any sense for the
mortal user.  There's such a sheer amount of information in them that
they are barely readable, their best purpose is probably debugging the
linker itself or the (avr-libc supplied) linker scripts.  I think most
users would be served better with just the symbol table output (IIRC,
that's what recent WinAVR produces by default).

Well, actually people would be rather advised to run avr-nm
theirselves, as there are many different useful options for different
purposes (like occasionally, you might want to run avr-nm with
--size-sort -S, but that's a poor default on the other hand), but some
people appear to have an abhorrence against typing such a simple
command manually on a command-line, so they'll simply never notice how
much useful different options are available beyond a simple flat file
that's always generated.

> include $(AVRLIB)/make/avrproj_make

I'd avoid including further files.  If nobody's expected to touch that
part anyway, why can't you copy the respective part over verbatim?

> buffer.o        : buffer.c              buffer.h
> uart2.o         : uart2.c               uart2.h                 global.h
> rprintf.o       : rprintf.c             rprintf.h
> a2d.o           : a2d.c                 a2d.h
> timer128.o      : timer128.c            timer128.h              global.h
> lcd.o           : lcd.c                 lcd.h                   global.h
> i2c.o           : i2c.c                 i2c.h                   global.h

Yet another personal opinion: as long as there's only two or three
prerequisite targets, the tabbing might be OK, but it's not really
better readable than reducing all that to just a single space each.
After all, the relation that is most interesting is everything on one
line, while the above optically prefers columns (which are completely
unrelated at all).

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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