Noeud:A Refreshing Change, Noeud « Previous »:Targets and Dependencies, Noeud « Up »:The Make Utility



A Refreshing Change

Near the start of this chapter we stated that Make keeps files up to date. In each of the examples so far, we have given Make a target that it must bring up to date: hello, helloagain and hello.o. On each occasion, Make has found that there is no such file and tried to determine a way to create one from its inference model. If a target is already up to date with respect to its dependencies then Make will notice, and not go to the trouble of refreshing it:

     $ ls -ltr
     total 9
     -rw-r--r--   1 gary     users       100 Sep 16 13:40 hello.c
     -rwxr-xr-x   1 gary     users      5964 Sep 16 13:41 hello
     -rw-r--r--   1 gary     users       888 Sep 16 13:43 hello.o
     $ make hello.o
     make: `hello.o' is up to date.
     $ make hello
     gcc   hello.o   -o hello
     $ ls -ltr
     total 18
     -rw-r--r--   1 gary     users       100 Sep 16 13:40 hello.c
     -rw-r--r--   1 gary     users       888 Sep 16 13:43 hello.o
     -rwxr-xr-x   1 gary     users      5964 Sep 16 13:44 hello
     $ ./hello
     Hello, World!
     

Make is using the modification timestamp of these file to decide whether the target file is out of date with respect to the files it depends on. Here, hello.c has not been changed since hello.o was last refreshed, so when asked to make hello.o, Make doesn't recompile. The program hello is actually older than hello.o to start with, so when we ask for hello to be refreshed, Make does indeed relink it from the newer hello.o.

The strategy used by Make for refreshing targets depends on the files that are present in the build directory. Originally, with only hello.c available, Make compiled directly from source to the program hello, but in the previous example where a hello.o object file was also available, Make took the simpler route of relinking hello directly from the object file. There is no magic involved here: the search order through Make's database of candidate file name suffixes tries less processor intensive matches first. This is important when it comes to complex builds, where Make is able to minimise the amount of recompilation that is performed by making the best use of intermediate files.

Make was developed in the early days of UNIX to automate the task of recompiling applications from of source files and libraries. Before Make was invented developers had to use shell scripts to recompile everything whenever an application was rebuilt.