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

> 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