Re: WIP: About CMake v2 - Mailing list pgsql-hackers
| From | Craig Ringer |
|---|---|
| Subject | Re: WIP: About CMake v2 |
| Date | |
| Msg-id | CAMsr+YF3Bv8vMTTPoPhQnmughReEJKGXvO+XOFc9Tsg_XmmRvQ@mail.gmail.com Whole thread Raw |
| In response to | Re: WIP: About CMake v2 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: WIP: About CMake v2
Re: WIP: About CMake v2 |
| List | pgsql-hackers |
On 27 November 2015 at 12:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Euler Taveira <euler@timbira.com.br> writes:
> On 26-11-2015 14:06, YUriy Zhuravlev wrote:
>> I meant that support for older versions of CMake I'll do when will implement
>> other functions.
> I think you don't understand the point: start with the *right* cmake
> version because you could have to redo (a lot of) your work or have your
> patch rejected because you don't follow our advice.
The way Yuriy wants to do it is not necessarily wrong. He might end up
with cleaner code if he starts by making a cmake-3 implementation and then
figures out how to back-port to cmake-2, rather than starting with the
more limited language to begin with.
Or maybe not. But I doubt it's open and shut.
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?
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.
We are. Or rather, the people within the community who perform the thankless task of packaging are.
The people who need to be involved here are the PGDG package maintainers for apt.postgresql.org and yum.postgresql.org. If you can convince them that adding CMake 3.x as a build-dependency is acceptable and that it's worth the pain/hassle required to ensure it's available you might avoid the backport to CMake 2.8. Especially if someone else has already done the work to backport CMake 3.x to wheezy, RHEL6 etc and there's a repo we can just import the packages from or rebuild into PGDG.
A packaged version of the CMake needed will be vital for PGDG packages. There's around about zero chance you'll get anywhere with the requirement to hand-compile CMake to build packages. If you can't list it as a build-depends and have the package fetched from a well-established repo (PGDG, the distro repo, or distro official backports) I think you'd have to support the older CMake instead.
Devrim at least has been fairly willing to backport packages and bundle them into the PGDG repo when they're required to build newer versions of things like PostGIS. Not without frustration and problems, though. I can't say anything about the apt repo in this regard.
(I've CC'd Devrim)
pgsql-hackers by date: