On Thu, Jun 21, 2012 at 05:00:39PM -0700, Allen Martin wrote:
Change the mkdir commands for the object directories to be more general purpose. This fixes an issue when building for SPL where SRCTREE and OBJTREE are the same, but $(obj) is under SPLTREE.
Signed-off-by: Allen Martin amartin@nvidia.com
board/avionic-design/plutux/Makefile | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/board/avionic-design/plutux/Makefile b/board/avionic-design/plutux/Makefile index d96d043..6bd394e 100644 --- a/board/avionic-design/plutux/Makefile +++ b/board/avionic-design/plutux/Makefile @@ -25,8 +25,11 @@
include $(TOPDIR)/config.mk
-ifneq ($(OBJTREE),$(SRCTREE)) -$(shell mkdir -p $(obj)../common $(obj)../../nvidia/common) +ifeq ($(wildcard $(obj)../common),) +$(shell mkdir -p $(obj)../common) +endif +ifeq ($(wildcard $(obj)../../nvidia/common),) +$(shell mkdir -p $(obj)../../nvidia/common) endif
I verified the other boards that reach up and over to ../common and ../../nvidia/common also fail, it's just that this directory doesn't get removed on a "make clobber" so once the directories are made it works fine from then on.
I couldn't figure a good way of moving this up to a higher level. The problem the build assumes all object files go to $(obj) and it's only when evaluating the $(obj)%.o: %.c rule that we really know where the object is going to end up (because the %.c has a relative path in it). Putting extra logic in that rule seems like it would slow the build down a lot for the general case, so I think it's better just to put the explicit mkdirs in the Makefiles where we reach up and over.
-Allen