[EMAIL PROTECTED] wrote: > 1 > 2 # List all paths here that include code to be compiled
Let's take a look at this. > 3 VPATH = \ > 4 $(PROJ_BASE)/model/ \ > 5 $(PROJ_BASE)/packet/ \ > 6 $(PROJ_BASE)/pkt_bfm/ \ > 7 $(PROJ_BASE)/stim/ \ > 8 $(PROJ_BASE)/pkt_trans_env/ So at first glance it would appear that this uses the VPATH mechanism automatically search for prerequisites. > 18 SRCS := $(wildcard *.cpp) $(notdir $(foreach > dir,$(VPATH),$(wildcard $(dir)/*.cpp))) But, hahahaha, then explicit wildcarding is used to find the files. The special features of VPATH are not relied upon; it's just used as an ordinary variable. You could replace this variable with, say $(SOURCE_DIRS) and everything should still work. > 19 > 20 # Build object list from SRCS, but placed in SC_OBJ_DIR > 21 OBJS = $(addprefix $(SC_OBJ_DIR)/,$(SRCS:.cpp=.o)) And, furthermore, the .o files are then calculated from these source files. So no implicit directory searching is done for those either! > 36 $(SC_OBJ_DIR)/%.o : %.cpp > 37 $(SCCOM) $< > 38 @sed -e 's|^[^:]*:|$(SC_OBJ_DIR)/&|' $*.d > > $(SC_OBJ_DIR)/$*.P; > \ > 39 sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \ > 40 -e '/^$$/ d' -e 's/$$/ :/' < $*.d >> > $(SC_OBJ_DIR)/$*.P; \ > 41 rm -f $*.d This vendor compiler supposedly takes all of GCC's options (claimed below). Then why is a sed hack employed to rename the dependency file, and to alter the target name? The gcc option -MF can be used to set the name of the dependency file, and -MT to set the target name within the dependency file. Why use this .P suffix? Leave it at .d. > This is working so far in my limited testing, but I'm a little > concerned about this going forward. Obviously, as the number of modules > increases, VPATH and the number of include directories will grow. I'm > not too worried about the inefficiencies of searching... I'm more > worried about hitting a hard limit on VPATH if we end up with a very > large number of modules. Since you aren't actually exploiting VPATH, that point is moot. You have a foreach loop that calls wildcard expansion over each directory in that path, collecting the result into another big string. What you may find that if the project grows very large, having this structure centralized in one place will lead to a lot of people concurrently editing this one little file. Any time someone adds a code subdirectory, they will have to edit the variable which lists the code subdirectories. That is why larger projects use a cascade of include makefiles for this. _______________________________________________ help-gnu-utils mailing list help-gnu-utils@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-utils
