[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
best practices regarding pulling together components across directories
From: |
Robert P. J. Day |
Subject: |
best practices regarding pulling together components across directories |
Date: |
Mon, 18 Jul 2011 06:53:32 -0400 (EDT) |
User-agent: |
Alpine 2.02 (DEB 1266 2009-07-14) |
i'm curious about best practices advice in the following situation:
===== start
vpath *.c dir1
vpath *.c dir2
vpath *.c dirn
vpath *.o objdir1
vpath *.o objdir2
-include (lots of .d names here)
all: target
lots of *.o references here
===== end
i was just handed a Makefile with that structure and, yes, it works
fine. however, given the number of "vpath" definitions, there's no
question that, as you read the Makefile to get a feeling for where all
the bits and pieces come from, it can sometimes be confusing to know
the origin of each component. yes, vpath is a terrifically useful
feature, but it also annoyingly obscures from *where* each component
comes from since, naturally, it just says, "hey, here's a bunch of
places to go look for stuff if you need it."
is there a standard for this sort of thing? i have no problem with
being more verbose if it makes the Makefile clearer. it is, of
course, possible to hard-code the names of each of those components
but that's taking things to the other extreme.
advice? is there a happy medium that is understood in the make
community as the cleanest way to do this? thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- best practices regarding pulling together components across directories,
Robert P. J. Day <=