Craig Ringer <craig.rin...@2ndquadrant.com> writes: > On 9 Nov. 2016 06:37, "Yury Zhuravlev" <u.zhurav...@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