On Fri, 20 Feb 2015 05:49:21 -0500, Jeff King <peff@xxxxxxxx> wrote: > 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. I always use prove $ prove -v t1234.sh > > 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 -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Attachment:
pgpVBV45Vrgqx.pgp
Description: OpenPGP digital signature