Skip site navigation (1) Skip section navigation (2)

Re: About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Dave Page <dpage(at)pgadmin(dot)org>
Subject: Re: About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)
Date: 2008-12-29 12:49:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
Peter Eisentraut wrote:
> On Sunday 21 December 2008 00:59:27 Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>> We (i.e. probably Magnus and I in the first instance) should think about
>>> creating a bit of a cookbook if we're going to persist with this build
>>> system.
>> Well, we were going to try CMake, but we need somebody to do the work.
> It did play around with CMake a while back.  It works OK.  I had libpq and 
> psql building, for example. 

I did a similar thing for pgAdmin, and I found it pretty easy to do.
However, I think Dave spent some time on doing the "plugins" for
detecting wxWidgets and such. The point being that I think creating the
replacement parts for autoconf are a lot harder than creating them for
the make parts of the system.

How much of that did you look at?

> The problem I see is that converting the build 
> system will probably take many man-hours, and in the meantime, it would 
> essentially create yet another build system to maintain.  Plus, we are not 
> sure, of course, whether we will end up adopting CMake.

Yes, that is the problem. It will take some time, and we don't know.
Now, once it's up to working order we *could* probably get rid of (or at
least very drastically reduce) the current MSVC build stuff, which would
get us back down in the number of build systems. But during the actual
work we'll certainly have one extra, yes.

> My preferred approach now is that the existing makefiles need to be refactored 
> more aggressively first, using make functions.  We could incidentally design 
> those functions similar to the CMake declarations, so a conversion, if we 
> decided to do one, would be simple.  But doing that properly would require a 
> newer GNU make version, so it needs some consideration first.  (I'm not 
> talking about last week's release, but more like 4 years old versus the 10 
> years old that we currently require.)

That makes sense. I wonder how much that is going to require to be
rewritten in the MSVC build stuff. We don't actually parse the "guts" of
the Makefiles there, we just look for things like the list of object
files etc. Would those be affected?

I'm also a bit concerned about the mingw platform, given the experiences
I've had with toolchain compatibility there... But if it's 4 years old,
we're *probably* safe...


In response to


pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2008-12-29 12:53:59
Subject: Updates of SE-PostgreSQL 8.4devel patches (r1368)
Previous:From: Peter EisentrautDate: 2008-12-29 12:40:56
Subject: Re: dblink vs SQL/MED

pgsql-committers by date

Next:From: Robert HaasDate: 2008-12-29 14:13:30
Subject: Re: PostGr and MSSQL
Previous:From: Peter EisentrautDate: 2008-12-29 11:25:12
Subject: About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group