From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christoph Berg <cb(at)df7cb(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Updating config.guess/config.sub for ppc64le |
Date: | 2014-05-13 14:05:45 |
Message-ID: | 19901.1399989945@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christoph Berg <cb(at)df7cb(dot)de> writes:
> Re: Tom Lane 2014-05-10 <27476(dot)1399729986(at)sss(dot)pgh(dot)pa(dot)us>
>> Our normal procedure is
>> o update config.guess and config.sub at the start of beta
>> (from http://savannah.gnu.org/projects/config)
> Fwiw, shouldn't that also happen in back branches?
No, we are not in the habit of back-patching such changes, at least
not automatically. I'd be willing to consider it once the new scripts
have survived a beta-testing cycle ... however, a look at our commit
logs shows we have never actually updated config.guess/config.sub in
any back branch.
> Updating config.* there gives you portability to new architectures for
> free - and there should be no risk of breaking anything.
The policy of not back-patching dates back to circa 2000, when new
config scripts *routinely* broke things due to changes in what they
printed on some machines (again, there's lots of evidence on this point
in our commit history). Perhaps that's less of a concern nowadays.
Still, there seems to be zero field demand for doing this.
As for "new architectures for free", nope --- spinlock assembly code
is usually the gating factor for that, not the config scripts.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-05-13 14:13:53 | Re: btree_gist valgrind warnings about uninitialized memory |
Previous Message | Alvaro Herrera | 2014-05-13 13:55:26 | Re: New timezones used in regression tests |