something i just now noticed -- in order for a kernel source tree to
be usable to run make in it and do the configuring and building
elsewhere with "O=", that source tree must be reasonably clean, but
it's not clear why.
the salient part of the top-level Makefile is here, around line 960:
=====
# prepare3 is used to check if we are building in a separate output directory,
# and if so do:
# 1) Check that make has not been executed in the kernel src $(srctree)
# 2) Create the include2 directory, used for the second asm symlink
prepare3: include/config/kernel.release
ifneq ($(KBUILD_SRC),)
@$(kecho) ' Using $(srctree) as source for kernel'
$(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/config ]; then \
echo " $(srctree) is not clean, please run 'make mrproper'";\
echo " in the '$(srctree)' directory.";\
/bin/false; \
fi;
$(Q)if [ ! -d include2 ]; then \
mkdir -p include2; \
ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm; \
fi
endif
=====
so if the source tree contains either a .config file or the
directory include/config, you can't use it for remote building, and
you'll be told to clean that source tree with "make mrproper" first.
but why should this be necessary?
certainly, it's the *remote* directory's .config file that's
relevant here so the local one should make no difference. *perhaps*
the local include/config directory would somehow interfere with the
configure/build depending on how the include paths are set up but,
again, it's the *remote* directory's include/config directory that
would be used, no?
forcing the local source directory to be "clean" might allow the
build process to be a bit sloppier than it should be, and might be
easier, but i can't help thinking that it shouldn't take much work to
be able to remove that restriction. after all, *none* of the actual
source files change because of the configure/build, so why should work
in the local directory have any effect at all on a remote build? or
am i missing something?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
"Kernel Newbie Corner" column @ linux.com: http://cli.gs/WG6WYX
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
