One of the complaints that I continue to hear is that kbuild
is lacking a way to 'remember' the ARCH and CROSS_COMPILE
values originally used.
Likewise we have people that change ARCH settings and get
a lot of build errors due to asm symlink pointing at the
wrong directory.
This patch tries to address this by saving ARCH and
CROSS_COMPILE settings and error out if user specify
anohter ARCH or CROSS_COMPILE setting.
If there is inconsistency then error out and suggest
to run make mrproper.
This will as a side-effect prevent a build with the wrong
asm symlink.
The settings are stored in the build directory in a file
named "Kbuild.config" (should it be a .dot file?).
I have tested it here with success - but please give
it a try in your setup and let me know if anything breaks.
The patch is on top of latest linus tree but should apply
with some fuzz to -mm too (at least it apply on top of
my kbuild.git tree).
PS. I do not like adding additional cruft to the top-level
Makefile but did not find an easy way to push this to
kconfig.
Sam
diff --git a/Makefile b/Makefile
index 6fc97bf..9f6d03f 100644
--- a/Makefile
+++ b/Makefile
@@ -182,8 +182,33 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
# Default value for CROSS_COMPILE is not to prefix executables
# Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
-ARCH ?= $(SUBARCH)
-CROSS_COMPILE ?=
+# Kbuild save the ARCH and CROSS_COMPILE setting in Kbuild.config
+# Restore these settings and check that user did not specify
+# conflicting values.
+Kbuild.config: ;
+noconfigcheck-targets := clean mrproper distclean help %config
+
+ifneq ($(wildcard Kbuild.config),)
+ -include Kbuild.config
+ ifeq ($(filter $(noconfigcheck-targets),$(MAKECMDGOALS)),)
+ ifneq ($(CROSS_COMPILE),)
+ ifneq ($(CROSS_COMPILE),$(KBUILD_CROSS_COMPILE))
+ $(error CROSS_COMPILE changed from "$(KBUILD_CROSS_COMPILE)" \
+ to "$(CROSS_COMPILE)". Use "make mrproper" to fix it up)
+ endif
+ endif
+ ifneq ($(ARCH),)
+ ifneq ($(KBUILD_ARCH),$(ARCH))
+ $(error ARCH changed from "$(KBUILD_ARCH)" \
+ to "$(ARCH)". Use "make mrproper" to fix it up)
+ endif
+ endif
+ endif
+ CROSS_COMPILE := $(KBUILD_CROSS_COMPILE)
+ ARCH := $(KBUILD_ARCH)
+else
+ ARCH ?= $(SUBARCH)
+endif
# Architecture as present in compile.h
UTS_MACHINE := $(ARCH)
@@ -351,6 +376,12 @@ scripts_basic:
# To avoid any implicit rule to kick in, define an empty command.
scripts/basic/%: scripts_basic ;
+# Save CROSS_COMPILE and ARCH for subsequent make invocations
+PHONY += Kbuild.config.save
+Kbuild.config.save:
+ $(Q)echo KBUILD_ARCH := $(ARCH) > Kbuild.config
+ $(Q)echo KBUILD_CROSS_COMPILE := $(CROSS_COMPILE) >> Kbuild.config
+
PHONY += outputmakefile
# outputmakefile generates a Makefile in the output directory, if using a
# separate output directory. This allows convenient use of make in the
@@ -413,7 +444,7 @@ ifeq ($(config-targets),1)
include $(srctree)/arch/$(ARCH)/Makefile
export KBUILD_DEFCONFIG
-config %config: scripts_basic outputmakefile FORCE
+config %config: scripts_basic outputmakefile Kbuild.config.save FORCE
$(Q)mkdir -p include/linux include/config
$(Q)$(MAKE) $(build)=scripts/kconfig $@
@@ -853,7 +884,10 @@ PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3
# 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
+prepare3: include/config/kernel.release Kbuild.config.save
+ifneq ($(KBUILD_CROSS_COMPILE)$(KBUILD_ARCH),)
+ $(Q)echo ' Using ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE)'
+endif
ifneq ($(KBUILD_SRC),)
@echo ' Using $(srctree) as source for kernel'
$(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/config ]; then \
@@ -919,10 +953,10 @@ define filechk_version.h
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
endef
-include/linux/version.h: $(srctree)/Makefile FORCE
+include/linux/version.h: $(srctree)/Makefile prepare2 FORCE
$(call filechk,version.h)
-include/linux/utsrelease.h: include/config/kernel.release FORCE
+include/linux/utsrelease.h: include/config/kernel.release prepare2 FORCE
$(call filechk,utsrelease.h)
# ---------------------------------------------------------------------------
@@ -1050,7 +1084,7 @@ CLEAN_FILES += vmlinux System.map \
MRPROPER_DIRS += include/config include2 usr/include
MRPROPER_FILES += .config .config.old include/asm .version .old_version \
include/linux/autoconf.h include/linux/version.h \
- include/linux/utsrelease.h \
+ include/linux/utsrelease.h Kbuild.config \
Module.symvers tags TAGS cscope*
# clean - Delete most, but leave enough to build external modules
On Mon, Oct 08, 2007 at 10:02:55PM +0200, Sam Ravnborg wrote:
> One of the complaints that I continue to hear is that kbuild
> is lacking a way to 'remember' the ARCH and CROSS_COMPILE
> values originally used.
Yea, finally.
What about, that this is the first ever prompt, that must be shown and
written to the .config?
The zeroth one is an config entry of kernel version(s), .config can
configure and thus build successfully.
This are among other ideas about kconfig/kbuild, you know nothing
about yet.
So, what do you think?
Also, i'd like to propose sequencing of config-enable-build-this-unit
in config file(s), thus Makefile(s) (sometimes very small and stupid)
will be not necessary. Additional link ordering can be supplied as
meta-config information there. Shell scripting, very ugly in the view
of make syntax, will be natural in config files. Extending build
process to get hidden dependencies or right linking/other magic is
part of particular configuration. Hm?
And i want to repeat this to the wall:
make is stupid `test -nt` (non POSIX, but accepted my shells and GNU test
feature). Making any kind of hashing to make dream of kbuild-2.5
developers/fans -- more complete `up-to-date' heuristic possible, is just
like `md5sum > $OBJDIR/heuristic.com`, which is config selectable (for
those, who don't like a bit of slowdown).
--
-o--=O`C
#oo'L O
<___=E M
On Mon, Oct 08, 2007 at 10:02:55PM +0200, Sam Ravnborg wrote:
>...
> The settings are stored in the build directory in a file
> named "Kbuild.config" (should it be a .dot file?).
>...
A .dot file sounds better.
And even if not, generated files should IMHO not share the Kbuild*
namespace with non-generated files.
Apart from this I like the patch.
> Sam
>...
cu
Adrian
BTW: I'm currently trying without success to understand why the
drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
named "Makefile".
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
>
> BTW: I'm currently trying without success to understand why the
> drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
> named "Makefile".
or the inverse ;-) Why all Makefiles (but the top level one ) are not
named Kbuild, considering that they are not valid (standalone) Makefile.
ciao
cate
>
> What about, that this is the first ever prompt, that must be shown and
> written to the .config?
Two issues to fix before we can do this:
1) chocie values cannot have more than one prompt
2) We need to share much more Kconfig* between the individual architectures
First step is to let all arch's use drivers/Kconfig
Let's get the two items above solved then we can revisit adding arch selection
to kconfig (where it belongs in the end).
And neither require a rewrite of kconfig...
> Also, i'd like to propose sequencing of config-enable-build-this-unit
> in config file(s), thus Makefile(s) (sometimes very small and stupid)
> will be not necessary. Additional link ordering can be supplied as
> meta-config information there. Shell scripting, very ugly in the view
> of make syntax, will be natural in config files. Extending build
> process to get hidden dependencies or right linking/other magic is
> part of particular configuration. Hm?
Discussed before but so far no patches has shown up.
Sam
On Tue, 9 Oct 2007 06:17:43 +0200 Sam Ravnborg wrote:
> >
> > What about, that this is the first ever prompt, that must be shown and
> > written to the .config?
> Two issues to fix before we can do this:
> 1) chocie values cannot have more than one prompt
> 2) We need to share much more Kconfig* between the individual architectures
> First step is to let all arch's use drivers/Kconfig
2) isn't terribly difficult, just takes some time and willingness
of $arch maintainers to some changes, but please explain a bit more
why it is needed...?
> Let's get the two items above solved then we can revisit adding arch selection
> to kconfig (where it belongs in the end).
> And neither require a rewrite of kconfig...
>
> > Also, i'd like to propose sequencing of config-enable-build-this-unit
> > in config file(s), thus Makefile(s) (sometimes very small and stupid)
> > will be not necessary. Additional link ordering can be supplied as
> > meta-config information there. Shell scripting, very ugly in the view
> > of make syntax, will be natural in config files. Extending build
> > process to get hidden dependencies or right linking/other magic is
> > part of particular configuration. Hm?
> Discussed before but so far no patches has shown up.
---
~Randy
On Mon, 8 Oct 2007 21:53:16 -0700 Randy Dunlap wrote:
> On Tue, 9 Oct 2007 06:17:43 +0200 Sam Ravnborg wrote:
>
> > >
> > > What about, that this is the first ever prompt, that must be shown and
> > > written to the .config?
> > Two issues to fix before we can do this:
> > 1) chocie values cannot have more than one prompt
> > 2) We need to share much more Kconfig* between the individual architectures
> > First step is to let all arch's use drivers/Kconfig
>
> 2) isn't terribly difficult, just takes some time and willingness
> of $arch maintainers to some changes, but please explain a bit more
> why it is needed...?
Maybe I didn't read carefully: "to add arch selection to kconfig"..
arch/cris using drivers/Kconfig: patch is below (maintainer is
cc-ed)
> > Let's get the two items above solved then we can revisit adding arch selection
> > to kconfig (where it belongs in the end).
> > And neither require a rewrite of kconfig...
> >
> > > Also, i'd like to propose sequencing of config-enable-build-this-unit
> > > in config file(s), thus Makefile(s) (sometimes very small and stupid)
> > > will be not necessary. Additional link ordering can be supplied as
> > > meta-config information there. Shell scripting, very ugly in the view
> > > of make syntax, will be natural in config files. Extending build
> > > process to get hidden dependencies or right linking/other magic is
> > > part of particular configuration. Hm?
> > Discussed before but so far no patches has shown up.
---
From: Randy Dunlap <[email protected]>
Move arch/cris to using drivers/Kconfig for its drivers config list.
When all arches do this, Sam can make more interesting improvements
to .config files.
Using drivers/Kconfig adds these kconfig files to cris:
connector, misc, ata, message/fusion (not avail.), macintosh (not avail.),
i2c, spi, w1, power, hwmon, mfd, video, hid, mmc, leds,
infiniband (not avail.), edac (not avail.), rtc, dma, auxdisplay,
kvm (not avail.), uio, and lguest (not avail.).
Many of these are already enabled/disabled per arch., so adding that
for cris can be done as required.
"not avail." means that this menu is not valid for this arch.
and won't be presented to users when running 'make *config'.
Signed-off-by: Randy Dunlap <[email protected]>
---
arch/cris/Kconfig | 40 +---------------------------------------
1 file changed, 1 insertion(+), 39 deletions(-)
--- linux-2.6.23-rc9-git6.orig/arch/cris/Kconfig
+++ linux-2.6.23-rc9-git6/arch/cris/Kconfig
@@ -153,49 +153,11 @@ source arch/cris/arch-v10/drivers/Kconfi
endmenu
-source "drivers/base/Kconfig"
-
# standard linux drivers
-source "drivers/mtd/Kconfig"
-
-source "drivers/parport/Kconfig"
-
-source "drivers/pnp/Kconfig"
-
-source "drivers/block/Kconfig"
-
-source "drivers/md/Kconfig"
-
-source "drivers/ide/Kconfig"
-
-source "drivers/scsi/Kconfig"
-
-source "drivers/ieee1394/Kconfig"
-
-source "drivers/message/i2o/Kconfig"
-
-source "drivers/net/Kconfig"
-
-source "drivers/isdn/Kconfig"
-
-source "drivers/telephony/Kconfig"
-
-#
-# input before char - char/joystick depends on it. As does USB.
-#
-source "drivers/input/Kconfig"
-
-source "drivers/char/Kconfig"
-
-#source drivers/misc/Config.in
-source "drivers/media/Kconfig"
+source "drivers/Kconfig"
source "fs/Kconfig"
-source "sound/Kconfig"
-
-source "drivers/usb/Kconfig"
-
source "arch/cris/Kconfig.debug"
source "security/Kconfig"
> > 2) We need to share much more Kconfig* between the individual architectures
> > First step is to let all arch's use drivers/Kconfig
>
> 2) isn't terribly difficult, just takes some time and willingness
> of $arch maintainers to some changes, but please explain a bit more
> why it is needed...?
A prerequisite for moving ARCH selection to Kconfig is that we
read in all Kconfig files for all architectures.
To do so efficient we should avoind including the same Kconfig
file for each architecture which is obviously the case today.
The efficiency comes both with respect to reading the files but
also memory consumption. If we read in drivers/Kconfig only once
then we will avoid some duplication compared to reading drivers/Kconfig
once for each architecture.
The structure we should aim for is something like a top-level
Kconfig file that pull in relevant parts from the kernel tree
and where the arch Kconfig only pull in additional Kconfig files
from that arch.
When we get this far we will have a more logical structure
in the Kconfig file and their distribution.
But the showstopper is the part with choice value that cannot have more
than a single prompt so when we have the same choice value
used in two arch Kconfig files then kconfig will warn and the
choice will do the wrong thing.
I never took a deeper look at this - I seem to get distracted each
time I try to understand all the inner details of the kconfig
use of data structures.
Sam
On Mon, Oct 08, 2007 at 11:12:56PM +0200, Adrian Bunk wrote:
> On Mon, Oct 08, 2007 at 10:02:55PM +0200, Sam Ravnborg wrote:
> >...
> > The settings are stored in the build directory in a file
> > named "Kbuild.config" (should it be a .dot file?).
> >...
>
> A .dot file sounds better.
I will make it ".kbuild".
Droppeing the .config bits of the name will hopefully avoid that
people mess with it manually.
> BTW: I'm currently trying without success to understand why the
> drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
> named "Makefile".
Giacomo explained this already..
But I have never done a global renaming - the
pain/benefit ratio seems too low.
Sam
On Tue, Oct 09, 2007 at 06:17:43AM +0200, Sam Ravnborg wrote:
> >
> > What about, that this is the first ever prompt, that must be shown and
> > written to the .config?
> Two issues to fix before we can do this:
> 1) chocie values cannot have more than one prompt
what occupying all my time now is to try to make fast and easy (text/tty)
user interface, based solely on TERM=linux capability. It is such, but
deep in ncurses/lxdialog wrappers. Having more flexible TUI without
all past stereotypes is the major point in making any progress for
flexible configuration interface. Remember, how blind `select` hurts.
It does due to UI limitations in first place, IMHO.
> 2) We need to share much more Kconfig* between the individual architectures
> First step is to let all arch's use drivers/Kconfig
All syntax wars are over, now order is the second thing to achieve. Like
in x86 merge case, this is purely technical thing with a bit of manual
work after that. sed magic for (nearly any kind :) of textual processing
i can guarantee without (yet another) C (like fixdep.c, parts of
sumversion.c, etc.)
> Let's get the two items above solved then we can revisit adding arch selection
> to kconfig (where it belongs in the end).
> And neither require a rewrite of kconfig...
Since i try to do test driven development, it's more easy for me to
understand/fix/test today's things via making bits from scratch. Fresh
view can do more on debugging of the logic level also.
____
Sam Ravnborg <[email protected]> writes:
>
> -ARCH ?= $(SUBARCH)
> -CROSS_COMPILE ?=
Can you do this in a way that there are still these ARCH/CROSS_COMPILE
lines that are just overriden when empty or have their default value?
This way defaults could be still patched in for special cases.
-Andi
On Tue, Oct 09, 2007 at 08:03:33AM +0200, Sam Ravnborg wrote:
> On Mon, Oct 08, 2007 at 11:12:56PM +0200, Adrian Bunk wrote:
>...
> > BTW: I'm currently trying without success to understand why the
> > drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
> > named "Makefile".
> Giacomo explained this already..
> But I have never done a global renaming - the
> pain/benefit ratio seems too low.
Either keep all as "Makefile" or rename all.
But being inconsequent creates maximum confusion.
> Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Oct 09, 2007 at 11:39:21AM +0200, Andi Kleen wrote:
> Sam Ravnborg <[email protected]> writes:
> >
> > -ARCH ?= $(SUBARCH)
> > -CROSS_COMPILE ?=
>
> Can you do this in a way that there are still these ARCH/CROSS_COMPILE
> lines that are just overriden when empty or have their default value?
>
> This way defaults could be still patched in for special cases.
If it is OK to drop the $(SUBARCH) assingment like this then yes.
ARCH ?=
CROSS_COMPILE ?=
I was wondering why we had the empty CROSS_COMPILE assigment and this
explains why.
But why patch something in here in the fisrt place?
It seems to be a workaround for the actual issue this patch addresses - no?
Sam
On Tue, Oct 09, 2007 at 12:00:30PM +0200, Sam Ravnborg wrote:
> On Tue, Oct 09, 2007 at 11:39:21AM +0200, Andi Kleen wrote:
> > Sam Ravnborg <[email protected]> writes:
> > >
> > > -ARCH ?= $(SUBARCH)
> > > -CROSS_COMPILE ?=
> >
> > Can you do this in a way that there are still these ARCH/CROSS_COMPILE
> > lines that are just overriden when empty or have their default value?
> >
> > This way defaults could be still patched in for special cases.
>
> If it is OK to drop the $(SUBARCH) assingment like this then yes.
> ARCH ?=
> CROSS_COMPILE ?=
As long as both UML and normal architectures work still out of the
box yes
> I was wondering why we had the empty CROSS_COMPILE assigment and this
> explains why.
> But why patch something in here in the fisrt place?
> It seems to be a workaround for the actual issue this patch addresses - no?
Mostly.
The difference is that Kbuild.config would likely contain other stuff
too that might be not fit into a patch? Ok it's not a big difference.
-Andi
On Tue, Oct 09, 2007 at 12:00:30PM +0200, Sam Ravnborg wrote:
> If it is OK to drop the $(SUBARCH) assingment like this then yes.
> ARCH ?=
> CROSS_COMPILE ?=
Does the UML build still work when you do that?
Jeff
--
Work email - jdike at linux dot intel dot com
On Tue, Oct 09, 2007 at 10:09:06AM -0400, Jeff Dike wrote:
> On Tue, Oct 09, 2007 at 12:00:30PM +0200, Sam Ravnborg wrote:
> > If it is OK to drop the $(SUBARCH) assingment like this then yes.
> > ARCH ?=
> > CROSS_COMPILE ?=
>
> Does the UML build still work when you do that?
The original behaviour is kept is ARCH is not set on the
commandline and saved in .kbuild (Kbuild.config in the patch).
The logic goes basically like this:
If there is no .kbuild file then set ARCH = $(SUBARCH)
else set ARCH = saved ARCH from .kbuild.
And then a bit sanity check that the user does not
try to change architecture in the middle.
I actually used um as testing ground for this patch so
it works for um in my way of building um.
I considered switching architectures automagically
but concluded that in most cases when a user change ARCH
then that's because the user forgot to specify ARCH or more
seldom forgot what ARCH was being built in that directory.
Sam
On Mon, 8 Oct 2007 22:02:55 +0200
Sam Ravnborg <[email protected]> wrote:
> One of the complaints that I continue to hear is that kbuild
> is lacking a way to 'remember' the ARCH and CROSS_COMPILE
> values originally used.
> Likewise we have people that change ARCH settings and get
> a lot of build errors due to asm symlink pointing at the
> wrong directory.
Yeah, almost happens at daily basis for me :)
>
> This patch tries to address this by saving ARCH and
> CROSS_COMPILE settings and error out if user specify
> anohter ARCH or CROSS_COMPILE setting.
> If there is inconsistency then error out and suggest
> to run make mrproper.
>
> This will as a side-effect prevent a build with the wrong
> asm symlink.
Sounds like a good idea.
>
> The settings are stored in the build directory in a file
> named "Kbuild.config" (should it be a .dot file?).
>
> I have tested it here with success - but please give
> it a try in your setup and let me know if anything breaks.
>
> The patch is on top of latest linus tree but should apply
> with some fuzz to -mm too (at least it apply on top of
> my kbuild.git tree).
>
> PS. I do not like adding additional cruft to the top-level
> Makefile but did not find an easy way to push this to
> kconfig.
>
> Sam
>
> diff --git a/Makefile b/Makefile
> index 6fc97bf..9f6d03f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -182,8 +182,33 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
> # Default value for CROSS_COMPILE is not to prefix executables
> # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
>
> -ARCH ?= $(SUBARCH)
> -CROSS_COMPILE ?=
> +# Kbuild save the ARCH and CROSS_COMPILE setting in Kbuild.config
> +# Restore these settings and check that user did not specify
> +# conflicting values.
> +Kbuild.config: ;
> +noconfigcheck-targets := clean mrproper distclean help %config
> +
> +ifneq ($(wildcard Kbuild.config),)
> + -include Kbuild.config
> + ifeq ($(filter $(noconfigcheck-targets),$(MAKECMDGOALS)),)
> + ifneq ($(CROSS_COMPILE),)
> + ifneq ($(CROSS_COMPILE),$(KBUILD_CROSS_COMPILE))
> + $(error CROSS_COMPILE changed from "$(KBUILD_CROSS_COMPILE)" \
> + to "$(CROSS_COMPILE)". Use "make mrproper" to fix it up)
> + endif
> + endif
> + ifneq ($(ARCH),)
> + ifneq ($(KBUILD_ARCH),$(ARCH))
> + $(error ARCH changed from "$(KBUILD_ARCH)" \
> + to "$(ARCH)". Use "make mrproper" to fix it up)
> + endif
> + endif
> + endif
> + CROSS_COMPILE := $(KBUILD_CROSS_COMPILE)
> + ARCH := $(KBUILD_ARCH)
> +else
> + ARCH ?= $(SUBARCH)
> +endif
>
> # Architecture as present in compile.h
> UTS_MACHINE := $(ARCH)
> @@ -351,6 +376,12 @@ scripts_basic:
> # To avoid any implicit rule to kick in, define an empty command.
> scripts/basic/%: scripts_basic ;
>
> +# Save CROSS_COMPILE and ARCH for subsequent make invocations
> +PHONY += Kbuild.config.save
> +Kbuild.config.save:
> + $(Q)echo KBUILD_ARCH := $(ARCH) > Kbuild.config
> + $(Q)echo KBUILD_CROSS_COMPILE := $(CROSS_COMPILE) >> Kbuild.config
> +
> PHONY += outputmakefile
> # outputmakefile generates a Makefile in the output directory, if using a
> # separate output directory. This allows convenient use of make in the
> @@ -413,7 +444,7 @@ ifeq ($(config-targets),1)
> include $(srctree)/arch/$(ARCH)/Makefile
> export KBUILD_DEFCONFIG
>
> -config %config: scripts_basic outputmakefile FORCE
> +config %config: scripts_basic outputmakefile Kbuild.config.save FORCE
> $(Q)mkdir -p include/linux include/config
> $(Q)$(MAKE) $(build)=scripts/kconfig $@
>
> @@ -853,7 +884,10 @@ PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3
> # 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
> +prepare3: include/config/kernel.release Kbuild.config.save
> +ifneq ($(KBUILD_CROSS_COMPILE)$(KBUILD_ARCH),)
> + $(Q)echo ' Using ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE)'
> +endif
> ifneq ($(KBUILD_SRC),)
> @echo ' Using $(srctree) as source for kernel'
> $(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/config ]; then \
> @@ -919,10 +953,10 @@ define filechk_version.h
> echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
> endef
>
> -include/linux/version.h: $(srctree)/Makefile FORCE
> +include/linux/version.h: $(srctree)/Makefile prepare2 FORCE
> $(call filechk,version.h)
>
> -include/linux/utsrelease.h: include/config/kernel.release FORCE
> +include/linux/utsrelease.h: include/config/kernel.release prepare2 FORCE
> $(call filechk,utsrelease.h)
>
> # ---------------------------------------------------------------------------
> @@ -1050,7 +1084,7 @@ CLEAN_FILES += vmlinux System.map \
> MRPROPER_DIRS += include/config include2 usr/include
> MRPROPER_FILES += .config .config.old include/asm .version .old_version \
> include/linux/autoconf.h include/linux/version.h \
> - include/linux/utsrelease.h \
> + include/linux/utsrelease.h Kbuild.config \
> Module.symvers tags TAGS cscope*
>
> # clean - Delete most, but leave enough to build external modules
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, Oct 09, 2007 at 06:34:35PM +0200, Sam Ravnborg wrote:
> I actually used um as testing ground for this patch so
> it works for um in my way of building um.
Great, thanks.
Jeff
--
Work email - jdike at linux dot intel dot com