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 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.