From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Euler Taveira <euler(at)timbira(dot)com(dot)br>, YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Devrim Gündüz <devrim(at)gunduz(dot)org> |
Subject: | Re: WIP: About CMake v2 |
Date: | 2015-11-27 06:14:18 |
Message-ID: | 29413.1448604858@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> One thing to consider: I can't imagine backporting this to all supported
> back branches, it'd be a switch for the next release. Right?
Agreed.
> That means he doesn't have to worry about what RH / Debian policy for their
> old versions is. RH isn't going to release PostgreSQL 9.7 or whatever for
> RHEL6, Debian isn't going to release it for Wheezy, etc.
Well, they won't if we make it impossible for them to do so.
More generally, I do not buy this argument for one second as a reason why
we can demand latest-and-greatest cmake, rather than something that's
likely to be readily available on a wide variety of platforms. Devrim is
not the only person in the world who will be needing to build PG on RHEL6,
or even older platforms.
If you take a close look at our build requirements, you will notice a
general distaste for insisting on latest anything. cmake is not going
to escape that project bias. Do you really think a project that still
works with C89, Perl 5.8.something, Python 2.3, bison 1.875, yadda yadda
is readily going to accept a patch that requires this year's cmake?
It would take a fairly impressive technical argument why working with
older cmakes is impossible/impractical before that will happen.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-11-27 06:23:37 | Re: WIP: About CMake v2 |
Previous Message | Craig Ringer | 2015-11-27 05:50:20 | Re: WIP: About CMake v2 |