help-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make question : How to handle autodependencies with source in multip


From: Doug
Subject: Re: make question : How to handle autodependencies with source in multiple directories
Date: 18 Jan 2007 06:50:20 -0800
User-agent: G2/1.0

Kaz,

Thanks for your feedback, and thanks for the tip on the gcc -MT option.
I missed that in the man page.
About the use of VPATH, I found that I do need to use it, and in fact
the special features of it are used when searching for prerequisites
for this rule:
    36  $(SC_OBJ_DIR)/%.o : %.cpp

If I replace VPATH with another variable it fails to find the .cpp file
for a given .o file.

To address your question about the .P files and all that sed, that was
based on Paul Smith's suggestion for avoiding the 'no rule to make
target' errors.
The explanation is here:
http://make.paulandlesley.org/autodep.html#norule

Regards,
Doug

Kaz Kylheku wrote:
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]