pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig.ringer@2ndquadrant.com>
Cc: YUriy Zhuravlev <u.zhuravlev@postgrespro.ru>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: About CMake v2
Date: Tue, 08 Nov 2016 22:47:34 -0500
Message-ID: <12172.1478663254@sss.pgh.pa.us> (raw )
In-Reply-To: <CAMsr+YFK+Ve8q+iFxoNysX0ePPvEvFUdMVZge+VRkJKb2eR9Aw@mail.gmail.com >
References: <CAPfS4ZzwscpK2MeE73==wBOAMndW1UuvktSL6TqXAatok+WHzg@mail.gmail.com >
<CAPfS4Zw8UReHG12RmpYYb3REqSN7Knx8coXg5_oT35HfCwggww@mail.gmail.com >
<CAB7nPqThtTWyh4vaYSjwm=Q_nAJzVbo=_F9nkPmA68v6bD38Kw@mail.gmail.com >
<29526280-50e2-495b-99e1-ccd4e16ffd05@postgrespro.ru >
<CAB7nPqSWtRhZDYuFVy5jBd8AOjdNiwwM8B9fazKArZs2Hd+rWA@mail.gmail.com >
<CAB7nPqTHwOT7WfV33ywyFS6NhSEr46C+S6jWS3sR20UDN7XP0w@mail.gmail.com >
<5a8a9610-722f-49df-b609-35842fe4c8d6@postgrespro.ru >
<CAB7nPqR_Cxv67kOOOQjrKx9cvc5Yn=9wzJyFoLxdc_qj2+TU9w@mail.gmail.com >
<0d8bf7e7-db42-44d8-aac5-65ff407cb60f@postgrespro.ru >
<af9694db-858b-c15a-9c5a-bcbccf933ca0@2ndquadrant.com >
<6cd3400f-a1bd-40ac-b2c9-e7e221f548eb@postgrespro.ru >
<CAMsr+YFK+Ve8q+iFxoNysX0ePPvEvFUdMVZge+VRkJKb2eR9Aw@mail.gmail.com >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Craig Ringer <craig.ringer@2ndquadrant.com> writes:
> On 9 Nov. 2016 06:37, "Yury Zhuravlev" <u.zhuravlev@postgrespro.ru> wrote:
>> This approach I see only in Postgres project and not fully understood.
>> Can you explain me more what reasons led to this approach?
> It's predictable. The default has the same result for everyone. I quite
> like it myself.
It's advantageous from a packaging standpoint, precisely because it's
predictable: either you get the set of features you expect, or you get
a build failure. Years ago we were more on the "opportunistic" side
of things, and we had problems with packages sometimes silently losing
features. A pretty-recent example is that OpenSSL changed their APIs
in 1.1.0 so that our configure probe failed. With an opportunistic
approach, that would have meant builds silently going from "ssl yes"
to "ssl no". That's not good.
So this is really not open for negotiation. As Peter said upthread,
what we are looking for in a CMake reimplementation is that it behaves
exactly like the Autoconf version does. To the extent that you are unable
or unwilling to duplicate that behavior, you increase the odds that
we'll reject this work.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (160+ messages) latest in thread
Message-ID: <12172.1478663254@sss.pgh.pa.us>
Permalink: ../12172.1478663254@sss.pgh.pa.us/
Also on: postgresql.org/message-id/12172.1478663254@sss.pgh.pa.us
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, craig.ringer@2ndquadrant.com, u.zhuravlev@postgrespro.ru, peter.eisentraut@2ndquadrant.com
Subject: Re: WIP: About CMake v2
In-Reply-To: <12172.1478663254@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox