Re: WIP: About CMake v2

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: WIP: About CMake v2
Дата
Msg-id CA+Tgmoa4YVONuV+xPFe242JUYpsRB8O31YZ8sJm4tXmRY5sndA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: About CMake v2  (Andres Freund <andres@anarazel.de>)
Ответы Re: WIP: About CMake v2  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: WIP: About CMake v2  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: On-demand running query plans using auto_explain and signals
Следующее
От: Robert Haas
Дата:
Сообщение: Re: icc vs. gcc-style asm blocks ... maybe the twain can meet?