git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Feb 20, 2015, 10:36 UTC
Message-ID
<54E70E2B.8000604@drmicha.warpmail.net>
In-Reply-To
<20150220014801.GB16124@peff.net>
Jeff King venit, vidit, dixit 20.02.2015 02:48:
Show 27 quoted lines
> 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 survives a cd, sure... 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 ;) )

Show 9 quoted lines
> 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.

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

Michael
Previous: Jeff KingNext: Jeff King
Message 18 of 23 in “Interested in helping open source friends on HP-UX?”
  1. Junio C HamanoDec 11, 2014
  2. H.Merijn BrandFeb 18, 2015
  3. Michael J GruberFeb 18, 2015
  4. Jeff KingFeb 18, 2015
  5. Junio C HamanoFeb 18, 2015
  6. Jeff KingFeb 18, 2015
  7. Michael J GruberFeb 19, 2015
  8. H.Merijn BrandFeb 19, 2015
  9. Michael J GruberFeb 19, 2015
  10. Jeff KingFeb 19, 2015
  11. Michael J GruberFeb 19, 2015
  12. H.Merijn BrandFeb 19, 2015
  13. Michael J GruberMar 3, 2015
  14. H.Merijn BrandMar 3, 2015
  15. Michael J GruberMar 3, 2015
  16. H.Merijn BrandMar 3, 2015
  17. Jeff KingFeb 20, 2015
  18. Michael J GruberFeb 20, 2015
  19. Jeff KingFeb 20, 2015
  20. H.Merijn BrandFeb 20, 2015
  21. H.Merijn BrandFeb 18, 2015
  22. H.Merijn BrandFeb 18, 2015
  23. David AguilarFeb 21, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.