On Wednesday 16 July 2008 18:21, Robert P. J. Day wrote: > > (i've been away from BB for quite some time and am just getting back > to it, so forgive what will undoubtedly be some dumb questions for a > while.) > > i'm curious about the need for the hack(?) as is found in, for > example, applets/usage.c: > > ... > /* Just #include "autoconf.h" doesn't work for builds in separate > * object directory */ > #include "../include/autoconf.h" > ... > > but why can't the build process recognize that the build is being > done in a separate object directory and fix the header include paths > accordingly for the subsequent compile step? it doesn't sound that > hard to do.
Try to build it, and you'll see why it doesn't work. If you find a nicer way to do it, I'm interested. > and in the top-level Makefile, we have: > > # Use LINUXINCLUDE when you must reference the include/ directory. > # Needed to be compatible with the O= option > > ok, but where is LINUXINCLUDE actually being set or used? > > $ grep -rw LINUXINCLUDE * > Makefile:# Use LINUXINCLUDE when you must reference the include/ directory. > Makefile:export CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS > $ > > from here, it doesn't appear that that variable is being used a > whole lot. Hehe :) The Makefile is way more awkward than that, because it was stolen and adapted from Linux kernel almost 1:1. It talks about modules and System.map! :) On the plus side, it made build process more reliable. "make -j N" magically started working etc... -- vda _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox