On 2017-02-10 10:22:34 -0800, Andres Freund wrote: > On 2017-02-10 12:07:15 -0500, Robert Haas wrote: > > But also, I'm not really sure whether this conversion makes sense. I > > mean, any build system is going to require some work, and accordingly > > our present build systems require some work. cmake will require > > different work, but not necessarily less. The current system has a > > long history; we pretty much know it works. Switching will inevitably > > break some things. Maybe we'll end up better off in the long term, > > but maybe we won't. Things are pretty good now, so it seems like it > > would be easy for them to get worse rather than better. > > I do think it's kinda ok for people who've dealt with this for some > time. But for the first few times having to write autoconf macros is > quite intimidating. A somewhat less obscure way to deal with that is > worth something. As is better file dependency management, across > different environments. As is the IDE integration cmake is more and > more getting. As is properly builtin working caching of configure tests > (llvm first cmake run, 7.7s, second 2.54s). As is the fact that a lot of > big projects (llvm, kde, qt, and a lot of others) migrated to it. > > For me personally those benefits aren't worth that much. I've learned > autoconf stuff. I've scripting around autoconf caching. But for newer > people that's not true.
Craig's email just now reminded me of another advantage: Using cmake across the board, would mean we'd use the same ./configure alike logic on both windows and linux. To me that seems quite and advantage over managing pg_config.h.win32/config_default.pl manually/separately - we obviously have screwed up quite badly there in the past (cf376a4adc0805b0). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
