Re: WIP: About CMake v2 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WIP: About CMake v2
Date
Msg-id CA+Tgmoa4YVONuV+xPFe242JUYpsRB8O31YZ8sJm4tXmRY5sndA@mail.gmail.com
Whole thread Raw
In response to Re: WIP: About CMake v2  (Andres Freund <andres@anarazel.de>)
Responses Re: WIP: About CMake v2  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: WIP: About CMake v2  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Fri, Aug 28, 2015 at 11:39 AM, Andres Freund <andres@anarazel.de> wrote:
> I definitely can see some advantages. Non-broken dependencies around
> recursive make being a major one. But I'm also afraid it's a rather
> large undertaking. There's a fair number of special kind of rules, and
> we're probably not going to want to break pgxs for extensions.

Maybe we should merge all of the makefiles for subdirectories of
src/backend into a single makefile.  The major disadvantage would be
that you couldn't rebuild a subdirectory any more by typing make -C
src/backend/executor or whatever.  And I do do that sometimes, so
maybe it would be annoying, but presumably it would make the
dependency issues a lot easier to deal with.

I guess I'm a bit skeptical about the idea of porting to a new build
system.  There's a good chance of replacing the problems we know about
with new problems that are no less serious, but merely unknown to us.
But I'm not going to stand here and hold my breath if everyone else
thinks it's a good idea.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: On-demand running query plans using auto_explain and signals
Next
From: Robert Haas
Date:
Subject: Re: icc vs. gcc-style asm blocks ... maybe the twain can meet?