Re: Include ppc64le build type for back branches

Hi Tom

With --build=powerpc64le-unknown-linux-gnu in the config_opts section
of build-farm.conf,
the build and the regression were successful.

Well, by the time the decision is made on this, I have enabled only 9.4+
runs on ppc64le. The results from this buildfarm member 'clam' are now
being reported.

On Wed, Dec 9, 2015 at 12:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I don't really want to get into an argument about this, but is the
> > reason we haven't updated config.guess and config.sub in the past that
> > it presents an actual stability risk, or just that nobody's asked
> > before? Because the first one is a good reason not to do it now, but
> > the second one isn't.
>
> Well, I see at least one case in the git history where we explicitly
> declined to update config.guess/config.sub:
>
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Branch: master Release: REL9_3_BR [5c7603c31] 2013-06-04 15:42:02 -0400
> Branch: REL9_2_STABLE Release: REL9_2_5 [612ecf311] 2013-06-04 15:42:21
> -0400
>
> Add ARM64 (aarch64) support to s_lock.h.
>
> Use the same gcc atomic functions as we do on newer ARM chips.
> (Basically this is a copy and paste of the __arm__ code block,
> but omitting the SWPB option since that definitely won't work.)
>
> Back-patch to 9.2. The patch would work further back, but we'd also
> need to update config.guess/config.sub in older branches to make them
> build out-of-the-box, and there hasn't been demand for it.
>
> Mark Salter
>
>
> More generally, I think "does updating config.guess, in itself, pose
> a stability risk" is a false statement of the issue. The real issue is
> do we want to start supporting a new platform in 9.1-9.3; that is, IMO
> if we accept this request then we are buying into doing *whatever is
> needed* to support ppc64le on those branches. Maybe that will stop with
> config.guess/config.sub, or maybe it won't.
>
> Setting this precedent will also make it quite hard to reject future
> requests to back-patch support for other new platforms.
>
> I'm not planning to go to war about this issue either. But I do think
> there's a slippery-slope hazard here, and we should be prepared for
> the logical consequences of accepting such a request. Or if we're
> going to have a policy allowing this request but not every such request,
> somebody had better enunciate what that policy is.
>
> regards, tom lane
>
> (BTW, so far as direct stability hazards go, I would guess that the
> key question is how much version skew can be tolerated between autoconf
> and config.guess/config.sub. I have no idea about that; Peter E. might.
> But I do note that pre-9.4 branches use an older autoconf version.)
>

--
Sandeep Thakkar