Reputation: 19431
When a project depends on some other project which has its own makefile, recursive make is used like this:
LIBDIR := path/to/lib
LIBNAME := library.a
LIBPATH := $(LIBDIR)/$(LIBNAME)
$(LIBPATH):
$(MAKE) -C $(LIBDIR) $(LIBNAME)
However the obvious problem with this is that make is unable to determine the dependencies of the $(LIBPATH)
because it's defined in the recursive makefile in $(LIBDIR)
.
What I'm currently doing is using a .PHONY target to force the check if the sub-project needs rebuilding:
$(LIBPATH): always_build
$(MAKE) -C $(LIBDIR) $(LIBNAME)
.PHONY: always_build
While this allow me to trigger rebuild when it needed it still needs to walk through a lot of directories and invoke make a lot of times, just to find out nothing needs to be done.
Is there a way to get the dependencies out of the sub-makefile so I can add them as a dependencies of the $(LIBPATH)
so the sub-makefile is only invoked when it really need to be invoked?
Upvotes: 1
Views: 660
Reputation: 100781
If you mean, in an automated way then no. Even if there were it wouldn't make any sense.
In order to get those prerequisites you'd have to invoke make to compute them. Once that sub-make had computed them it would inform the parent make and the parent make would check the prerequisites then if any were out of date it would invoke the sub-make again which would re-compute the prerequisites to actually build the target.
Far from being MORE efficient, you'd actually be doing about three times as much work!
In a recursive make scenario, your current method of delegating the out-of-date computation to a sub-make is the best you can do.
What you're really asking is to use a non-recursive make environment where a single instance of make knows all the prerequisites and determines what is out of date. Note, however, that this does not really solve the problem of "not reading lots of makefiles".
Ultimately you can't know that your project is completely up to date, without checking that it's completely up to date... which means checking all the dependency relationships.
Upvotes: 1