Re: WIP: About CMake v2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: About CMake v2
Date: 2015-09-01 13:41:56
Message-ID: CA+Tgmoa4YVONuV+xPFe242JUYpsRB8O31YZ8sJm4tXmRY5sndA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 28, 2015 at 11:39 AM, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

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