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

[dcw . web]

Hi there,

I have been googling like crazy to come up with an appropriate Makefile
system for compiling C++ code that's in multiple directories and
determines the dependencies automatically. First, thanks to Paul Smith
for the excellent tutorial on auto-dependencies. Using that along with
VPATH I was able to get something to work, but I am wondering a few
things...

1. Is there a better way?
2. Am I crazy for trying this?

My basic requirements are to setup a structure that will do the
following...

1. Allow source code to reside in different directories
2. Automatically generate dependencies
3. Compiled objects will be placed in a different directory (I realize
this may not be ideal, but the tools I'm using does this automatically)
4. Do not recursively call make

So, here's my Makefile along with some comments. I should preface this
by saying I come from a chip-design background, not software
development. The actual C++ code uses the SystemC library, and the
compiler (sccom) is a vendor compiler that wraps around gcc.

     1
     2  # List all paths here that include code to be compiled
     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/
     9
    10  # Build include list which will hold each path in VPATH
    11  INCDIRS := $(foreach dir,$(VPATH),$(addprefix -I,$(dir)))
    12
    13  # Library location
    14  SC_LIB = work
    15  SC_OBJ_DIR = $(SC_LIB)/_sc
    16
    17  # Collect all source files in this dir and all dirs of VPATH
    18  SRCS := $(wildcard *.cpp) $(notdir $(foreach
dir,$(VPATH),$(wildcard $(dir)/*.cpp)))
    19
    20  # Build object list from SRCS, but placed in SC_OBJ_DIR
    21  OBJS = $(addprefix $(SC_OBJ_DIR)/,$(SRCS:.cpp=.o))
    22
    23  # Compile/link commands
    24  # -MMD option below is required so that the preprocessor will
generate dependency files
    25  SCCOM  = sccom -nologo -verbose -vv -scv -MMD $(INCDIRS)
    26  SCLINK = sccom -nologo -verbose -vv -scv -link
    27
    28  default: $(SC_LIB)/systemc.so
    29
    30  .PHONY: clean
    31
    32  $(SC_LIB)/systemc.so: $(OBJS)
    33          $(SCLINK)
    34
    35  ## autodependecy stuff based on
http://make.paulandlesley.org/autodep.html
    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
    42
    43  clean:
    44          -rm -rf work
    45          vlib work
    46
    47  echo:
    48          @echo VPATH: $(VPATH)
    49          @echo SRCS: $(SRCS)
    50          @echo OBJS: $(OBJS)
    51          @echo INCDIRS: $(INCDIRS)
    52
    53  # Include .P prerequisite files
    54  -include $(addprefix $(SC_OBJ_DIR)/,$(SRCS:.cpp=.P))
    55

The usage model for this is that each module will reside in it's own
directory, and any module that needs to be included in the build will
have its directory appended to VPATH.

VPATH/wildcards are used to create a list of all the source files
(*.cpp from each dir), which are then compiled using the vendor
compiler. As part of the compile the dependency files are generated
automatically (as described at
http://make.paulandlesley.org/autodep.html). The vendor compiler
(sccom) can take any gcc options, so the -MMD is included there.

The .cpp files do not include any paths in the #includes, so I also
create a list if include directories from VPATH.

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.

Any suggestions for improvement, corrections, or totally alternative
approaches would be appreciated.  And if there's a better place to ask
this question... by all means let me know.

Thanks,
-Doug