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

Re: [patch 00/16] Portability Patches for git-1.7.1 (v4)

From
Jeff King <peff@peff.net>
Date
Apr 27, 2010, 17:54 UTC
Message-ID
<20100427175442.GB13626@coredump.intra.peff.net>
In-Reply-To
<4BD7032D.9050508@drmicha.warpmail.net>
On Tue, Apr 27, 2010 at 05:30:53PM +0200, Michael J Gruber wrote:
Show 5 quoted lines
> Your diff -> test_cmp are certainly something we want to have in any
> case. The code changes look ugly, honestly, making the code much less
> readable, but it seems to be the only way to make those older platforms
> and compilers happy. (Erik pointed out some good ways to reduce the
> uglyness somewhat.)

I agree. We really need to make a decision here about how far backward we are willing to bend for older systems.

Solaris 2.6 was released in 1997, and Sun dropped support for it in 2006, four years ago. How long do we want to continue supporting it? And at what cost? If we have not hit end-of-life on it now, then what would be a reasonable time? And what defines end-of-life support for git? I am perfectly happy to carry a Solaris 2.6 section of the Makefile forever. But if it is going to cause code changes that make the code harder to read and maintain, is it worth it? Especially when one could probably just use gcc to build for those platforms. Sure, it may be less convenient for the builder, and it may not generate quite as good code as a vendor compiler, but to what degree should we care? Those platforms are an extreme minority, and we need to balance their impact on code that developers on every platform have to work with.

Furthermore, if we do take such changes, how are we going to manage portability going forward? Some constructs (like non-constant initializers) make the code much easier to read. People _will_ submit patches that use them. Is somebody going to be auto-building on all of these platforms with vendor compilers to confirm that nothing is broken?

If all of these questions seem like rhetorical "I am trying to convince you these patches aren't a good idea" questions, they're not meant as such. I think these are serious questions that need to be answered when evaluating portability patches.

-Peff
Previous: Michael J GruberNext: Andreas Schwab
Message 34 of 49 in “Portability Patches for git-1.7.1 (v4)”
  1. 00/16 Portability Patches for git-1.7.1 (v4)Gary V. Vaughan, Apr 27, 2010
  2. 01/16 user-cppflags.patchGary V. Vaughan, Apr 27, 2010
  3. 02/16 const-expr.patchGary V. Vaughan, Apr 27, 2010
  4. Erik Faye-LundApr 27, 2010
  5. Gary V. VaughanApr 27, 2010
  6. 03/16 pthread.patchGary V. Vaughan, Apr 27, 2010
  7. 04/16 Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git.Gary V. Vaughan, Apr 27, 2010
  8. Tor ArntsenApr 27, 2010
  9. Gary V. VaughanApr 28, 2010
  10. Tor ArntsenApr 28, 2010
  11. Jeff KingApr 28, 2010
  12. 05/16 diff-export.patchGary V. Vaughan, Apr 27, 2010
  13. 06/16 diff-test_cmp.patchGary V. Vaughan, Apr 27, 2010
  14. Jonathan NiederApr 27, 2010
  15. Gary V. VaughanApr 28, 2010
  16. Jonathan NiederApr 28, 2010
  17. Gary V. VaughanApr 28, 2010
  18. Jonathan NiederApr 28, 2010
  19. 07/16 diff-defaults.patchGary V. Vaughan, Apr 27, 2010
  20. 08/16 host-SunOS56.patchGary V. Vaughan, Apr 27, 2010
  21. 09/16 host-IRIX.patchGary V. Vaughan, Apr 27, 2010
  22. 10/16 host-HPUX10.patchGary V. Vaughan, Apr 27, 2010
  23. 11/16 host-HPUX11.patchGary V. Vaughan, Apr 27, 2010
  24. 12/16 host-OSF1.patchGary V. Vaughan, Apr 27, 2010
  25. Tor ArntsenApr 27, 2010
  26. Gary V. VaughanApr 27, 2010
  27. Tor ArntsenApr 27, 2010
  28. Gary V. VaughanApr 28, 2010
  29. 13/16 no-hstrerror.patchGary V. Vaughan, Apr 27, 2010
  30. 14/16 no-inet_ntop.patchGary V. Vaughan, Apr 27, 2010
  31. 15/16 no-socklen_t.patchGary V. Vaughan, Apr 27, 2010
  32. 16/16 no-inline.patchGary V. Vaughan, Apr 27, 2010
  33. Michael J GruberApr 27, 2010
  34. Jeff KingApr 27, 2010
  35. Andreas SchwabApr 27, 2010
  36. Jeff KingApr 28, 2010
  37. Gary V. VaughanApr 28, 2010
  38. Jeff KingApr 28, 2010
  39. Gary V. VaughanApr 28, 2010
  40. Gary V. VaughanApr 28, 2010
  41. Ævar Arnfjörð BjarmasonApr 28, 2010
  42. Michael J GruberMay 1, 2010
  43. Junio C HamanoMay 1, 2010
  44. Gary V. VaughanMay 3, 2010
  45. Øyvind A. HolmMay 2, 2010
  46. Gary V. VaughanApr 28, 2010
  47. Gary V. VaughanApr 29, 2010
  48. Gary V. VaughanMay 3, 2010
  49. Gary V. VaughanMay 4, 2010

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.