[patch 3/3] kconfig CROSS_COMPILE option

[patch 3/3] kconfig CROSS_COMPILE option

[akpm]

From: Roland McGrath <roland@redhat.com>

This adds CROSS_COMPILE as a kconfig string so you can store it in
.config.  Then you can use plain "make" in the configured kernel build
directory to do the right cross compilation without setting the
command-line or environment variable every time.

With this, you can set up different build directories for different kernel
configurations, whether native or cross-builds, and then use the simple:

	make -C /build/dir M=module-source-dir

idiom to build modules for any given target kernel, indicating which one
by nothing but the build directory chosen.

I tried a version that defaults the string with env="CROSS_COMPILE" so
that in a "make oldconfig" with CROSS_COMPILE in the environment you can
just hit return to store the way you're building it.  But the kconfig
prompt for strings doesn't give you any way to say you want an empty
string instead of the default, so I punted that.

Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 Makefile     |    3 +++
 init/Kconfig |    8 ++++++++
 2 files changed, 11 insertions(+)

diff -puN Makefile~kconfig-cross_compile-option Makefile
--- a/Makefile~kconfig-cross_compile-option
+++ a/Makefile
@@ -177,11 +177,14 @@ SUBARCH := $(shell uname -m | sed -e s/i
 # CROSS_COMPILE can be set on the command line
 # make CROSS_COMPILE=ia64-linux-
 # Alternatively CROSS_COMPILE can be set in the environment.
+# A third alternative is to store a setting in .config so that plain
+# "make" in the configured kernel build directory always uses that.
 # Default value for CROSS_COMPILE is not to prefix executables
 # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
 export KBUILD_BUILDHOST := $(SUBARCH)
 ARCH		?= $(SUBARCH)
 CROSS_COMPILE	?=
+CROSS_COMPILE	?= $(CONFIG_CROSS_COMPILE:"%"=%)
 
 # Architecture as present in compile.h
 UTS_MACHINE 	:= $(ARCH)
diff -puN init/Kconfig~kconfig-cross_compile-option init/Kconfig
--- a/init/Kconfig~kconfig-cross_compile-option
+++ a/init/Kconfig
@@ -76,6 +76,14 @@ config INIT_ENV_ARG_LIMIT
 	  variables passed to init from the kernel command line.
 
 
+config CROSS_COMPILE
+	string "Cross-compiler tool prefix"
+	help
+	  Same as running 'make CROSS_COMPILE=prefix-' but stored for
+	  default make runs in this kernel build directory.  You don't
+	  need to set this unless you want the configured kernel build
+	  directory to select the cross-compiler automatically.
+
 config LOCALVERSION
 	string "Local version - append to kernel release"
 	help
_

Re: [patch 3/3] kconfig CROSS_COMPILE option

[Michal Marek]

On 17.11.2009 23:45, akpm@linux-foundation.org wrote:
> From: Roland McGrath <roland@redhat.com>
> 
> This adds CROSS_COMPILE as a kconfig string so you can store it in
> .config.  Then you can use plain "make" in the configured kernel build
> directory to do the right cross compilation without setting the
> command-line or environment variable every time.
> 
> With this, you can set up different build directories for different kernel
> configurations, whether native or cross-builds, and then use the simple:
> 
> 	make -C /build/dir M=module-source-dir
> 
> idiom to build modules for any given target kernel, indicating which one
> by nothing but the build directory chosen.
> 
> I tried a version that defaults the string with env="CROSS_COMPILE" so
> that in a "make oldconfig" with CROSS_COMPILE in the environment you can
> just hit return to store the way you're building it.  But the kconfig
> prompt for strings doesn't give you any way to say you want an empty
> string instead of the default, so I punted that.

This was posted in September, then superseded by the "save ARCH &
CROSS_COMPILE" patch (commit 5755433), which was then reverted because
it was causing too many issues (commit 2331d1a). In light of the revert,
I think I like Roland's patch: It's an optional feature, i.e if one does
not set the config option, nothing changes. So unless someone sees a
problem that I'm not seeing, I'll add this to for-next.

How to check for $ARCH consistency after the include/asm symlink removal
is another problem, separate from this.

Michal