From: Pavel Roskin <proski@gnu.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: linux <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Saving ARCH and CROSS_COMPILE in generated Makefile
Date: Thu, 05 May 2005 17:56:11 -0400 [thread overview]
Message-ID: <1115330171.3838.24.camel@dv.roinet.com> (raw)
In-Reply-To: <20050505212003.GA16877@mars.ravnborg.org>
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
prev parent reply other threads:[~2005-05-05 21:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-04 23:11 [PATCH] Saving ARCH and CROSS_COMPILE in generated Makefile Pavel Roskin
2005-05-04 23:23 ` Al Viro
2005-05-05 3:18 ` Pavel Roskin
2005-05-05 21:20 ` Sam Ravnborg
2005-05-05 21:56 ` Pavel Roskin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1115330171.3838.24.camel@dv.roinet.com \
--to=proski@gnu.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.