Saving ARCH and CROSS_COMPILE in generated Makefile

Hello!

I don't want to specify ARCH and CROSS_COMPILE with every make invocation when cross-compiling the kernel. I believe they should be saved somewhere. The most natural place would be .config, but I guess it's not acceptable for some reason, or it would have been done long ago.

The second best place would be the Makefile generated in the build directory when the kernel is compiled outside the source tree. The patch below implements that.

Unfortunately, builds in the source directory would not profit from this patch. Perhaps we could always generate "makefile" or "GNUmakefile" in the build directory, but it would be another patch. Anyway, few people cross-compile their kernels, and it's not unreasonable to encourage them to use out-of-tree builds.

SUBARCH is not saved on purpose, since users are not supposed to override it.

Compiling external modules against the build tree does the right thing without ARCH and CROSS_COMPILE being specified.

Index: scripts/mkmakefile
===================================================================
@@ -21,6 +21,11 @@
 
 MAKEFLAGS += --no-print-directory
 
+ARCH = $ARCH
+CROSS_COMPILE = $CROSS_COMPILE
+
+export ARCH CROSS_COMPILE
+
 all:
 	\$(MAKE) -C \$(KERNELSRC) O=\$(KERNELOUTPUT)
 

Regards,
Pavel Roskin

WTF not? Consider, e.g. uml/i386 and uml/amd64.

In any case, there's no reason to mess with that at all. This stuff is trivally dealt with by a wrapper script that takes target name as its first argument (the rest is passed to make unchanged) and figures out ARCH, CROSS_COMPILE, SUBARCH and build directory by it. End of story.

Hello, Al!

Sorry, forgot to copy to LKML.

Agreed. See corrected patch below. SUBARCH is not set when not compiling for UML to avoid confusing but harmless output in Makefile like

ARCH = arm
SUBARCH = i386

Actually, UML doesn't currently build outside the kernel tree because a link to arch/um/Kconfig_arch is not created. This will need a separate fix.

I think SUBARCH ultimately should go to .config as a UML specific option (but the build system will have to learn how to get default values from the outside world). Until then, I'm fine with saving SUBARCH.

I'm using such script now. It's called kmake. I keep forgetting to run kmake instead of make, so it's an annoyance for me (usually it end up with a full screen of error messages, but I'm afraid I could get a mix of object files for different architectures in some cases). Maybe the wrapper should read .config? I'll rather contribute some code to Linux than to a local script.

I've been working with embedded systems for many years, and I know that it's very common to patch the top-level Makefile to set ARCH and CROSS_COMPILE. It is done so that all developers working on the code don't have to write wrappers and remember to use them every time.

Having ARCH and CROSS_COMPILE hardcoded in Makefile is inconvenient if one wants to compile the same source for another architecture to verify portability of the changes. That's exactly where having a separate build directory is handy.

I know, what is considered trivial for one person is an annoyance for another. What if Linux required to add arguments to the make command line to enable SMP and preemption? After all, one could put those arguments to the wrapper as well. It's convenient that we can configure the kernel once and forget about every choice we made. I want the same for ARCH and CROSS_COMPILE settings.

@@ -21,6 +21,12 @@
 
 MAKEFLAGS += --no-print-directory
 
+ARCH = $ARCH
+SUBARCH = `[ "$ARCH" = um ] && echo $SUBARCH`
+CROSS_COMPILE = $CROSS_COMPILE
+
+export ARCH SUBARCH CROSS_COMPILE
+
 all:
 	\$(MAKE) -C \$(KERNELSRC) O=\$(KERNELOUTPUT)
 

Regards,
Pavel Roskin

Use a Makefile called either makefile or GNUMakefile to call make with correct arguments. No kmake script required.
And no difference in behaviour using O= or not.
You could teach kmake to create such a file if not present.

Nope. .o files are rebuild if commandline changes. This works well. This works so well that when you change name of gcc you have to rebuild the kernel - no matter the arguments used.
It amy be a shift from gcc 2.96 to gcc 4.0.

Sam

Or we could teach scripts/mkmakefile to do it for all of us. I can post a patch that would call scripts/mkmakefile regardless of whether O= is used, and scripts/mkmakefile would generate makefile rather than Makefile.

Good to know. But my point still stands.

If I have a build tree already compiled for a specific architecture, and I'm going to compile an external driver against that tree, why do I need to set ARCH and CROSS_COMPILE to match those used during compilation? Why cannot the build system do it for me?

Also, if I want to recompile the kernel after changing the source, I want to run make in the build tree. That's what the generated Makefile is for. But if I overrode ARCH or CROSS_COMPILE, I have to remember to do it again. And that's what I want to fix.

I'm sure I can write a very intelligent script tuned for my system that would do the right thing and that will even set CROSS_COMPILE based on the architecture from .config file. But I want to share my code, not to hoard it.

Maybe I should try to implement saving ARCH and CROSS_COMPILE in .config file, but it would be more intrusive.

Regards,
Pavel Roskin