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.
Signed-off-by: Pavel Roskin <[email protected]>
Index: scripts/mkmakefile
===================================================================
--- 2aa9e4732d7014dcda4c0e80d2e377f52e2262e9/scripts/mkmakefile (mode:100644 sha1:c4d621b30d0db1649d99f9cebf31377cc2d8d32b)
+++ uncommitted/scripts/mkmakefile (mode:100644)
@@ -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
On Wed, May 04, 2005 at 07:11:07PM -0400, Pavel Roskin wrote:
> 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.
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.
On Thu, 2005-05-05 at 00:23 +0100, Al Viro wrote:
> On Wed, May 04, 2005 at 07:11:07PM -0400, Pavel Roskin wrote:
> > 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.
>
> WTF not? Consider, e.g. uml/i386 and uml/amd64.
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.
> 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.
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.
Signed-off-by: Pavel Roskin <[email protected]>
--- scripts/mkmakefile
+++ scripts/mkmakefile
@@ -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
> > 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.
>
> I'm using such script now. It's called kmake.
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.
> 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).
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
On Thu, 2005-05-05 at 23:20 +0200, Sam Ravnborg wrote:
> > > 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.
> >
> > I'm using such script now. It's called kmake.
>
> 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.
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.
> > 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).
>
> 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.
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