[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joerg Wunsch
Subject: Re: [avr-gcc-list] Makefile Procyon AVRlib vs AVR-libc and ANSI C
Date: Thu, 6 Oct 2005 07:07:58 +0200 (MET DST)

Patrick Blanchard <address@hidden> wrote:

(Dave already answered the questions about "specified-width integer
types" as the C99 standard calls them.)

> I cannot find a good teaching reference for this 'linking' part of
> the makefile, so I'm stuck here...

Oops, that's nothing about linking but the very basic "make" concept
about specifying dependencies.  Please read the GNU make manual (if
you don't know where to find it, Google should help you quickly).
Eric Weddington usually recommends something like the first 5

> buffer.o:buffer.c buffer.h

> what does this do in a makefile?

It says that buffer.o depends on buffer.c and buffer.h, i.e. if one of
the latter files is more recent than the target on the left-hand side,
the target needs to be rebuilt.

The way *how* make has to rebuild the target could follow in the next
line(s), indedented by a hard tabulator.  However, in your case, it is
not specified, so these lines only mention dependencies.  For this
kind of files (creation of a .o file from a .c file), make usually
uses so-called inference (or implicit) rules which tell how a file
name with one suffix is transferred into a file name with a different
suffix.  Many of these inference rules are already built right into
make, so the inference rule for the above might look like:

.SUFFIXES: .c .o

        $(CC) $(CFLAGS) -c $<

($< is a special variable naming the "implied source" that often can
only be used inside of inference rules.)

That's why you also see why sticking to the macro naming convention
might be important.  If you don't call the accumulated compiler
options for your C compiler "CFLAGS", you'll have to write a new
inference rule as well.  Otherwise, you can use the builtin rule.
Note that there are no inference rules for header (.h) files, as these
cannot compiled themselves.  Thus, if in the above case buffer.h has
been touched, make would still recompile buffer.c as it only has a
rule to compile a .c file into a .o file.

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]