From: Pavel Roskin <proski@gnu.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS
Date: Fri, 30 Sep 2005 09:41:02 -0400 [thread overview]
Message-ID: <1128087662.14543.14.camel@dv> (raw)
In-Reply-To: <7vek779kg0.fsf@assigned-by-dhcp.cox.net>
On Thu, 2005-09-29 at 22:46 -0700, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > +# explicitly what architecture to check for.
> > +SPARSE = sparse
> > +SPARSE_FLAGS = -D__$(shell uname -i)__
>
> : siamese; uname --version
> uname (coreutils) 5.2.1
> Written by David MacKenzie.
Apparently my uname 5.2.1 was heavily patched by Fedora. Note that
"uname -m" is not good enough, as it would give us i686 when i386 is
really needed.
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> : siamese; uname -i
> Try `uname --help' for more information.
>
> Better alternatives?
I hate to say that, but a better alternative is to fix sparse to act
like the native compiler by default (possibly with options to imitate
other architectures or to be fully arch-neutral).
I have some hacks in mind, but I don't really like them:
Not good for i686 with unpatched uname:
SPARSE_FLAGS = __$(shell uname -i 2>/dev/null || uname -m)__
gcc specific:
SPARSE_FLAGS = __$(shell $CC -dumpmachine | sed 's/-.*//')__
bash specific:
SPARSE_FLAGS = __$(shell echo $$HOSTTYPE)__
In any case, having SPARSE variable would be convenient.
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2005-09-30 13:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-29 20:46 [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS Pavel Roskin
2005-09-30 5:46 ` Junio C Hamano
2005-09-30 13:41 ` Pavel Roskin [this message]
2005-09-30 19:19 ` H. Peter Anvin
2005-09-30 22:14 ` Pavel Roskin
2005-09-30 22:16 ` H. Peter Anvin
2005-10-01 4:13 ` Pavel Roskin
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=1128087662.14543.14.camel@dv \
--to=proski@gnu.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).