| |||||||||||||
automake vs. GNU makeautomake vs. GNU makePosted Feb 7, 2008 5:18 UTC (Thu) by stevenj (guest, #421)In reply to: automake vs. GNU make by sward Parent article: LCA: Disintermediating distributions That's clear enough. Yes, using foo/main.c and bar/main.c in the Makefile rules will clearly work (unless you have one of the rare compilers that doesn't support -c -o, although you can hack around that with enough effort I suppose). It seems a bit ugly to me, though, that your subdirectory Makefiles (to be included) must be written differently depending on the name of the directory they are in. The analogous thing in a programming language would be, if you had a subroutine foo(), to require that all local variables be named with a "foo_" prefix.
(Log in to post comments)
automake vs. GNU make Posted Feb 7, 2008 5:54 UTC (Thu) by sward (subscriber, #6416) [Link]
That isn't really necessary for variable names (that you don't need to reference later), only
the source and targets need to be qualified. A fairly typical example:
# Define sources for this component:
MY_SRC = $(wildcard foo/*.c)
MY_OBJ = $(MY_SRC:.c=.o)
MY_TGT = foo/libfoo.a
# Additional flags and dependencies for building this component:
$(MY_OBJ): CPPFLAGS += -I foo
$(MY_TGT): $(MY_OBJ)
# Add these to the master Makefile's lists:
SOURCE += $(MY_SRC)
TARGET += $(MY_TGT)
CLEAN += $(MY_OBJ)
The next component can reuse MY_SRC etc. You wouldn't even need these variables, if you had
no need for target-specific variables or dependencies. (But of course, you usually do). If
you wanted to keep a reference to 'foo/libfoo.a', for use in other Makefiles, you might
replace MY_TGT with LIBFOO.
In short, you only need unique names for global variables; local ones can be overwritten.
You do need the component path ('foo' in this example) in a few spots, but it is trivial to
change that if the directory structure changes.
|
|||||||||||||