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:
htt
p://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.
_______________________________________________
help-gnu-utils mailing list
help-gnu-utilsgnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-utils
|