Re: Interested in helping open source friends on HP-UX?

[Jeff King <peff@peff.net>]

On Fri, Feb 20, 2015 at 11:36:27AM +0100, Michael J Gruber wrote:

> > 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 survives a cd, sure...

I think the interesting thing is that it survives running `./tXXXX`
rather than running the test through make.

> Now, change your config.mak before the cd and
> forget the make. Not everyone does
> 
> make -C t t3901-i18n-patch.sh
> 
> Though, having just discovered that shell completion works for that
> form, too, I may do it more often (and then complain about having to use
> GIT_TEST_OPTS ;) )

Yeah, I never use "make tXXXX" myself. But nor would I expect the tests
to respect a version of git I had not actually built. E.g., if you build
with NO_PERL, and then remove NO_PERL from your config.mak but do _not_
actually run "make", should that work? Ditto for NO_ICONV, for that
matter. The tests must match the binary, and the best guess we have
about the binary is the last thing we built.

Adding "git --build-options" would give us a better guess (it may not be
what the user _wanted_ to test, but it is what they _are_ testing).

> > 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.
> 
> Yep, that would be helpful in general. I don't think we should worry
> about GIT_TEST_INSTALLED too much. Who came up with that feature anyway...?

Clearly a crazy person. :) I am not saying it is a _bad_ idea. Only that
the responsibility to make sure the installed version matches the
current build parameters lies with the user (and for that matter, the
current set of tests; we add new tests that would fail on old versions,
and you cannot mix and match).

So an alternate explanation than "not widely used" is "all of the users
of it are responsible individuals who do not make bogus bug reports to
the list". :)

-Peff