Skip to content

Multiple makefiles

Jump to bottom
marksvc edited this page Jun 17, 2021 · 1 revision

.PHONY method

There are times when it is desirable to use more than one makefile for a project. For example, the test code for VwGraphics depends on the VwGraphics library, which has its own makefile.

The following lines in the test makefile will make the library if it does not already exist: 

 ../../lib/VwGraphics.o:
     @cd $(@D); $(MAKE)$(@F)
  • The @ before cd stops make from echoing the command
  • $(@D) is the directory (../../lib)
  • $(@F) is the file (VwGraphics.o)
This approach, however will only make the file if it does not exist. The file will not be rebuilt if it is out of date.

To use the smarts from the makefile in the lib directory, we can add VwGraphics.o to the dependencies of .PHONY. These dependencies will be rebuilt every time they are needed. 

 .PHONY: ../../lib/VwGraphics.o

However, with this approach, these files will be rebuilt even when they are not out of date.

Double colon Method

I've found what I think is the best way to use build products from another Makefile ("remote dependencies"). You want two things:

  1. To rebuild the current target if the remote dependency has changed
  2. To rebuild the remote dependency whenever this is needed

For example, suppose you are writing a test program for a library, libFoo.a, and that the test program is in a subdirectory of the directory where libFoo is built. Your test program's Makefile would contain the following dependency:

TestFoo: TestFoo.o ../libFoo.a

However, you want ../libFoo.a to be remade if it doesn't exist. So you include a rule like this:

../libFoo.a:
    $(MAKE) -C $(@D) $(@F)

This says to run make in the appropriate directory ($(@D), ..) to make the appropriate target ($(@F), libFoo.a). Unfortunately, unless libFoo.a doesn't exist, it won't be remade, even if it is out of date, because the current Makefile doesn't know about libFoo.a's dependencies.

The answer, I've found, is to use a double-colon rule for ../libFoo.a. If there are no dependencies, the target's commands will always be run, due to the slightly different meaning of double-colon rules. However, things that depend on this target won't be remade unless this target is actually rebuilt (ie the file's modification time changes).

However, there's still a slight annoyance. If libFoo.a doesn't need to be remade, you will get the message "make[1]: `libFoo.a' is up to date.". To avoid this, it's necessary to strengthen the recursive make command:

../libFoo.a::
    @$(MAKE) -C $(@D) $(@F) -q || \
     $(MAKE) -C $(@D) $(@F)

This runs two recursive make commands. The first, with a -q option, simply tests whether the target needs to be remade. The second, coupled to the first with the shell's OR operator (||) only runs if the first 'fails'. In addition, the leading @ is used to suppress echoing of the whole compound command.

For a really complex build, it would of course be expensive to run make twice in this way, but for most practical purposes the overhead isn't noticeable.

Clone this wiki locally