Michael Paquier <mich...@paquier.xyz> writes:
> Some of the portability changes removed in 0b16bb877 feel indeed
> obsolete, so it may not hurt to start an analysis from scratch to see
> the minimum amount of work that would be really required with the
> latest versions of xlc, using the newest compilers as a supported
> base.
Something I've been mulling over is whether to suggest that the
proposed "new port" should only target building with gcc.
On the one hand, that would (I think) remove a number of annoying
issues, and the average end user is unlikely to care which compiler
their database server was built with. On the other hand, I'm a strong
proponent of avoiding software monocultures, and xlc is one of the few
C compilers still standing that aren't gcc or clang.
It would definitely make sense for a new port to start by getting
things going with gcc only, and then look at resurrecting xlc
support.
> I'd like to think backporting these to stable branches should
> be OK at some point, once the new port is proving baked enough.
If things go as I expect, the "new port" would effectively drop
support for older AIX and/or older compiler versions. So back-
porting seems like an unlikely decision.
> Anyway, getting an access to such compilers to be able to debug issues
> on hosts that take less than 12h to just compile the code would
> certainly help its adoption.
+many
regards, tom lane
