From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig.ringer@2ndquadrant.com>
cc: YUriy Zhuravlev <u.zhuravlev@postgrespro.ru>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: About CMake v2
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>
Comments: In-reply-to Craig Ringer <craig.ringer@2ndquadrant.com>
	message dated "Wed, 09 Nov 2016 06:54:03 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12171.1478663254.1@sss.pgh.pa.us>
Date: Tue, 08 Nov 2016 22:47:34 -0500
Message-ID: <12172.1478663254@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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