On Tue, Apr 27, 2010 at 05:30:53PM +0200, Michael J Gruber wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html