Makefile doesn't detect header file change

[lovecreatesbeauty]

My Makefile doesn't detect the change of header files.

This little makefile follows sec 2.6 of GNU make manual, and I
remember it worked before when header files changed.

Where am i wrong?

Thanks

$ touch b.h
$ make
make: `a.out' is up to date.
$

$ pwd
/home/ljh/temp/src
$ ls
a.c b.c b.h Makefile
$ cat Makefile
CC = gcc
CFLAGS = -ansi -pedantic -Wall -W
LDFLAGS =
OBJS = a.o b.o
OUT = a.out

$(OUT) : $(OBJS)
$(CC) $(LDFLAGS) $^ -o $@

a.c b.c : b.h

..PHONY : clean

clean :
rm $(OUT) $(OBJS)

$ make
gcc -ansi -pedantic -Wall -W -c -o a.o a.c
a.c: In function ¡®main¡¯:
a.c:7: warning: implicit declaration of function ¡®b¡¯
gcc -ansi -pedantic -Wall -W -c -o b.o b.c
gcc a.o b.o -o a.out
$ touch b.c
$ make
gcc -ansi -pedantic -Wall -W -c -o b.o b.c
gcc a.o b.o -o a.out
$ make
make: `a.out' is up to date.
$ touch b.h
$ make
make: `a.out' is up to date.
$
$ make -v
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i486-pc-linux-gnu
$ uname -a
Linux debian 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/
Linux
$ cat /etc/debian_version
6.0.4
$

 

[Ian Collins]

My Makefile doesn't detect the change of header files.

This little makefile follows sec 2.6 of GNU make manual, and I
remember it worked before when header files changed.

Where am i wrong?

Posting here? Try are more appropriate group.

You probably need the enable dependency checking in your makefile.

 

[Kaz Kylheku]

My Makefile doesn't detect the change of header files.

a.c b.c : b.h

Here you are saying that a.c and b.c are objects that are built from b.h.

But that is not the case, since they are not built; a.c and b.c they are
primary objects with no dependencies.

It is b.o and a.o which depend on b.h.

$ touch b.h
$ make

Hmm, a better message might be "no rule to make a.c from b.h",
since you've declared the dependency, and a.c is out of date
with respect to b.h under that dependency, and there isn't
any way to make a.c from b.h".

 

[lovecreatesbeauty]

Here you are saying that a.c and b.c are objects that are built from b.h.

But that is not the case, since they are not built; a.c and b.c they are
primary objects with no dependencies.

It is b.o and a.o which depend on b.h.

Thank you very much for pointing this out.

Hmm, a better message might be "no rule to make a.c from b.h",
since you've declared the dependency, and a.c is out of date
with respect to b.h under that dependency, and there isn't
any way to make a.c from b.h".

Does my implicit rule for compiling cause the "no rule.." message, or
is it an implementation bug

 

[lovecreatesbeauty]

Here you are saying that a.c and b.c are objects that are built from b.h.

But that is not the case, since they are not built; a.c and b.c they are
primary objects with no dependencies.

It is b.o and a.o which depend on b.h.

I add auto-dependencies generation for header files to avoid specify
individual header for source files.

I tried use wildcard for the SRCS variable in Makefile, but caused
some errors.

$ cat Makefile
CC = gcc
CFLAGS = -ansi -pedantic -Wall -W
CPPFLAGS = -I include
LDFLAGS =
SRCS = a.c b.c
OBJS = $(patsubst %.c,%.o,$(SRCS))
OUT = a.out

vpath %.c src
vpath %.h include

$(OUT): $(OBJS)
$(CC) $(LDFLAGS) $^ -o $@

include $(SRCS:.c=.d)

%.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$

..PHONY : clean
clean:
rm *.d $(OBJS) $(OUT)

$
$ pwd
/home/ljh/temp
$
$ ls . ./src/ ./include/
..:
include Makefile src

../include/:
b.h

../src/:
a.c b.c
$

 

[Keith Thompson]

I add auto-dependencies generation for header files to avoid specify
individual header for source files.

I tried use wildcard for the SRCS variable in Makefile, but caused
some errors.

$ cat Makefile
CC = gcc
CFLAGS = -ansi -pedantic -Wall -W

[snip]

Makefiles aren't specific to C. You're likely to get better help in
comp.unix.programmer.