Alessandro Vesely wrote:
Noel Yap wrote:
IME, it's best to have a GNUmakefile in each directory (so anyone can do a gmake within any directory) and a, say, GNUprivate.mk file within each directory (that contains the non-common stuff).
The problem of recursing becomes apparent when there are inter-directory dependencies. Did you ever wish, while writing a makefile, that you had at hand all the dependencies already specified for another directory? In facts, writing recursively is easier and there is much more experience with it than with single makefile builds.
IME, inter-directory dependencies can be handled with non-recursive make. In fact, it's handled better than with recursive make.
IMHO, no amount of expertise can fix broken dependency graphs due to a broken infrastructure.
I've seen two philosophies on this: 1. gmake within any directory will build the entire project 2. gmake within any directory will build that directory and any subdirectories (a la recursive make)
I personally lean towards the second philosophy
me too.
which means that each GNUmakefile needs to include its corresponding GNUprivate.mk and its subdirectories' GNUprivate.mk's.
AFAIK, there is no recognized standard for writing these.
Right. The recognized standard uses recursive make which is broken. One will either conform to the standard with all its drawbacks or forge with something that works completely and correctly.
Of course there must be agreed variable naming conventions. However, should one code each file name with a variable prefix in front of it? E.g.,
TARGETS += $(PATH_TO_HERE)my_target $(PATH_TO_HERE)my_target : $(PATH_TO_HERE)my_obj1 $(PATH_TO_HERE)my_obj2
where PATH_TO_HERE is set to "this_subdir/" by the parent, or else is empty. That contradicts rules 3 and 4 in <http://make.paulandlesley.org/rules.html>, but there are no directives such as `include_and_cd' or even just `cd'.
In a non-recursive make, there is no cd.
There is vpath, but how do I know that a source file named just like mine will never appear in some upper directory? Furthermore, many rules work just smoothly when issued from the proper directory. I often write `$(MAKE) -C' when all I wanted to say was `cd'.
I've been able to resolve all the issues you mention using creative uses of eval and user functions. It takes time to come up with such an infrastructure because, as you say, expertise isn't widespread.
To minimize maintenance on GNUmakefile, a function is used that'll just shell out and execute a "find . -name GNUprivate.mk".
Otherwise, each GNUprivate.mk may include its subdirectories' GNUprivate.mk's. The $(wildcard) fuction may come handy for this.
Such functionality is common and so would be better left in the GNUmakefile rather than copied in each GNUprivate.mk.
In the end, ideally, all GNUprivate.mk would contain is a list of sources in the current directory, the list of goals (eg leaf targets) derived from the sources, and possibly one function call to provide the mapping from one to the other. Rules may be used for this last part but IME calling use functions is a more general solution than using rules (eg calling user functions may create rules on the fly).
Noel
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
