Re: make question : How to handle autodependencies with source in multiple directories

[Kaz Kylheku]

dcw.web@gmail.com 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.