From: Jeff King <peff@peff.net>
To: Andrew Rodland <andrew@cleverdomain.org>
Cc: git@vger.kernel.org
Subject: Re: USE_NSEC bug?
Date: Wed, 20 Mar 2013 03:53:44 -0400 [thread overview]
Message-ID: <20130320075344.GA8159@sigill.intra.peff.net> (raw)
In-Reply-To: <CABFQKmP6=Thhph4Ug+4LOBmzsVK42qBQYW2QHw87QD3019n+Kw@mail.gmail.com>
On Wed, Mar 20, 2013 at 02:36:32AM -0400, Andrew Rodland wrote:
> While investigating this StackOverflow question:
> http://stackoverflow.com/questions/15516168/how-to-cross-compile-git-for-arm
> I found that fetch-pack.c uses ST_MTIME_NSEC outside of the protection
> of #ifdef USE_NSEC. This results in a broken build if
> !defined(USE_NSEC) && !defined(NO_NSEC) and the target system doesn't
> happen to be recent glibc.
Right; the point of NO_NSEC is to tell git that your libc does not have
those fields. If it's not set, then it is a bug in your config.mak (or
in the autoconf script, if you are using it).
That being said, I really don't see the point of having both USE_NSEC
and NO_NSEC. If you do not set USE_NSEC (which most people do not; it is
off by default), what is the point of not setting NO_NSEC? As far as I
can tell, it means we will copy stat information out "struct st" into
the index, but we will not actually _use_ it for anything.
Should there just be a single option USE_NSEC that defaults to off? And
if it is not set, we do not even bother caring whether libc provides
nsec fields, since we are not going to use them for anything (i.e., we
just do the equivalent of NO_NSEC now).
Which I think is the direction you are proposing with your patches
below, but the rationale should be "why bother requiring users to use
the NO_NSEC knob explicitly when we know we do not care about its value
anyway".
But maybe there is some subtle reason I'm missing for having the two
options separate. Or maybe it's just a historical accident that we ended
up here.
-Peff
next prev parent reply other threads:[~2013-03-20 7:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 6:36 USE_NSEC bug? Andrew Rodland
2013-03-20 7:53 ` Jeff King [this message]
2013-03-20 17:04 ` Junio C Hamano
2013-03-20 17:09 ` Jeff King
2013-03-20 17:31 ` Junio C Hamano
2013-03-20 18:22 ` Andrew Rodland
2013-03-20 18:30 ` Jeff King
2013-03-20 18:52 ` Junio C Hamano
2013-03-20 19:00 ` Jeff King
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=20130320075344.GA8159@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=andrew@cleverdomain.org \
--cc=git@vger.kernel.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 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).