Thread: Make utility and Header Files.

If a change affects a header file we will recompile all files that include this header file since they could potentially be affected by the change. (Some of them might not be , but it pays to be conservative)

How can "some of them might not be?" Do you have an example?

an example of a change that technically would not need a recompile would be if you added some comments to the include file without changing anything else.

your makefile looks right to me.

Originally Posted by Salem

> How can "some of them might not be?" Do you have an example?
Consider using something like
$ gcc -MM foo.c
foo.o: foo.c foo.h
to provide you with accurate dependency rules.

Hmmm yes we take the dependencies with this option -MM it is the first time that I see this option though.

another question .... what does it mean with that

If the linker can't find the functions that are in file foo.c it may not know about the file

It means that the file in which the functions are defined ? For example if we call from foo.c two functions that are defined in another file for example foo2.c ... linker does not know the file foo2.c if can't find the functions?

and from this source -> UNIX Make

on the paragraph Simple Example (In the beginning) the description of how make will work is the same with C? (Because It says about C++ file1.cc for example not file1.c)

thank you in advance

Originally Posted by Mr.Lnx

Code:

demo.o : main.c f1.h
            gcc -c main.c

How does gcc -c main.c producde demo.o?

Originally Posted by Mr.Lnx

I read that the order of rules is arbitrary

For some make utilities, the first target in the make file is the default. Otherwise you'd have to specify which target you want built.

Originally Posted by Mr.Lnx

If a change affects a header file we will recompile all files that include this header file since they could potentially be affected by the change. (Some of them might not be , but it pays to be conservative). How can "some of them might not be?" Do you have an example?

If a change was made to a header file, such as a change to a structure that only one of the c programs uses, then the remaining c programs would not be affected.

Originally Posted by rcgldr

How does gcc -c main.c producde demo.o?

Code:

demo : main.o f1.o f2.o
           gcc -o demo main.o f1.o f2.o   
 
main.o : main.c f1.h
            gcc -c main.c
 
f1.o:  f1.c  f1.h f2.h
        gcc -c f1.c
f2.o:  f2.c f1.h f2.h
         gcc -c f2.c

I think now it's ok

Originally Posted by rcgldr

If a change was made to a header file, such as a change to a structure that only one of the c programs uses, then the remaining c programs would not be affected.

Aha a wider perception because you are talking about of entire programs not only one program which is made of many files... this has to do with portability(using the same header to other programs). That is what you want to say?

Originally Posted by Mr.Lnx

Code:

demo : main.o f1.o f2.o
           gcc -o demo main.o f1.o f2.o   
 
main.o : main.c f1.h
            gcc -c main.c
 
f1.o:  f1.c  f1.h f2.h
        gcc -c f1.c
f2.o:  f2.c f1.h f2.h
         gcc -c f2.c

Another way to do this :

Code:

# Use variables for the target ($@ = demo here) and the dependencies ($^ = main.o f1.o f2.o)
demo : main.o f1.o f2.o
           gcc -o $@ $^

# Define a generic rule for getting *.o from *.c.  $< is the .c file in this case
%.o : %.c 
        gcc -c $<

# Add additional dependencies for header files. They are on top of the  ".o needs a .c file" 
# rule above, so no need to include the .c files in this list as well
main.o : f1.h
f1.o:  f1.h f2.h
f2.o:  f1.h f2.h

The benefit is that you're not repeating things more than you need to - instead of repeating lists of files or actions several times, they're just in one place. That way when you add and remove files you only have to change them in one place rather than in several. Or if you modify the options you pass to gcc, you just have to do it in one place instead of for each .o:.c rule.