From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: "H.Merijn Brand" <h.m.brand@xs4all.nl>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: Interested in helping open source friends on HP-UX?
Date: Thu, 19 Feb 2015 20:48:01 -0500 [thread overview]
Message-ID: <20150220014801.GB16124@peff.net> (raw)
In-Reply-To: <54E5E347.4070401@drmicha.warpmail.net>
On Thu, Feb 19, 2015 at 02:21:11PM +0100, Michael J Gruber wrote:
> > It passes NO_ICONV through to the test suite, sets up a prerequisite,
> > disables some test scripts which are purely about i18n (e.g.,
> > t3900-i18n-commit), and marks some of the scripts with one-off tests
> > using the ICONV prereq.
>
> Hmm. I know we pass other stuff down, but is this really a good idea? It
> relies on the fact that the git that we test was built with the options
> from there. This assumptions breaks (with) GIT_TEST_INSTALLED, if not more.
>
> Basically, it may break as soon as we run the tests by other means than
> "make", which is quite customary if you run single tests.
>
> (And we do pass config.mak down, me thinks, but NO_ICONV may come from
> the command line.)
It's not quite so bad as you make out. We write the value to the
GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
load that in test-lib.sh. So:
make NO_ICONV=Nope
cd t
./t3901-i18n-patch.sh
works just fine (for this and for any of the other options we mark
there).
It won't work for GIT_TEST_INSTALLED, but that is not a new problem.
Fundamentally you cannot expect to test a version built without option X
without telling git _somehow_ that it was built that way.
I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
would have complained before. But if we really want to support it, I
think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
that "git --build-options" dumps it. It might also have value for
debugging and forensics in general.
> Jeff, you got it wrong. You should do the hard part and leave the easy
> part to us!
Oops. :)
-Peff
next prev parent reply other threads:[~2015-02-20 3:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-11 7:46 Interested in helping open source friends on HP-UX? Junio C Hamano
2015-02-18 16:00 ` H.Merijn Brand
2015-02-18 17:46 ` Michael J Gruber
2015-02-18 18:25 ` Jeff King
2015-02-18 18:47 ` Junio C Hamano
2015-02-18 18:57 ` Jeff King
2015-02-19 10:33 ` Michael J Gruber
2015-02-19 11:14 ` H.Merijn Brand
2015-02-19 11:20 ` Michael J Gruber
2015-02-19 12:54 ` Jeff King
2015-02-19 13:21 ` Michael J Gruber
2015-02-19 18:56 ` H.Merijn Brand
2015-03-03 14:55 ` Michael J Gruber
2015-03-03 15:30 ` H.Merijn Brand
2015-03-03 16:05 ` Michael J Gruber
2015-03-03 22:25 ` H.Merijn Brand
2015-02-20 1:48 ` Jeff King [this message]
2015-02-20 10:36 ` Michael J Gruber
2015-02-20 10:49 ` Jeff King
2015-02-20 11:24 ` H.Merijn Brand
2015-02-18 19:22 ` H.Merijn Brand
2015-02-18 19:20 ` H.Merijn Brand
2015-02-21 23:31 ` David Aguilar
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=20150220014801.GB16124@peff.net \
--to=peff@peff.net \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=h.m.brand@xs4all.nl \
/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).