Jeff King [off-list ref] writes:
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?
You can use "gcc -pedantic" to find these portability problems.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Tue, Apr 27, 2010 at 10:13:02PM +0200, Andreas Schwab wrote:
Jeff King [off-list ref] writes:
quoted
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?
You can use "gcc -pedantic" to find these portability problems.
Sort of. It reports much more than we necessarily need to fix to remain
portable to even remotely sane platforms. So it's a nice tool for
finding problems, but somebody needs to do the work of figuring out
which are important and which are not, and then periodically run with
-pedantic and sort out the results.
-Peff
Hi Jeff,
On Tue, Apr 27, 2010 at 10:08:16PM -0400, Jeff King wrote:
On Tue, Apr 27, 2010 at 10:13:02PM +0200, Andreas Schwab wrote:
quoted
Jeff King [off-list ref] writes:
quoted
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?
And that's fine. People who are trying to build will notice the
breakage on their platforms and likely submit patches in due course.
A portability guide in the source tree might help reduce the code
churn, I'd even be willing to draft it for you if you agree that it
would help. I think it would be just a few hundred words setting out
the 5 or 6 problems that I have to patch over-and-over when I port OS
packages to our older architectures...
quoted
You can use "gcc -pedantic" to find these portability problems.
Sort of. It reports much more than we necessarily need to fix to remain
portable to even remotely sane platforms. So it's a nice tool for
finding problems, but somebody needs to do the work of figuring out
which are important and which are not, and then periodically run with
-pedantic and sort out the results.
IMHO, unless it is a significant impediment to development of git,
then it makes sense to support any platform for which you have someone
prepared to maintain the port.
While our release cycle revs only 2 or 3 times per year, for as long
as I have customers who want me to port to their platforms, I will
continue to patch support for those platforms into our packages. I
think that it would be a shame if those ports were kept hidden away on
our servers and only benefited our customers rather than integrated
into upstream for the benefit of the whole community.
So the real question is whether uglification of unportable code is so
unacceptable that git wants to wilfully reject external maintenance of
ports to end-of-life but none-the-less deployed and active
architectures?
Cheers,
--
Gary V. Vaughan (gary@thewrittenword.com)
On Wed, Apr 28, 2010 at 09:19:22AM +0000, Gary V. Vaughan wrote:
quoted
quoted
quoted
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?
And that's fine. People who are trying to build will notice the
breakage on their platforms and likely submit patches in due course.
That was sort of implicit in my questions. _Is_ there somebody who is
going to be building on these platforms that will notice the breakage?
But it sounds from the rest of your mail like you are willing to do so,
which is at least encouraging.
-Peff