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).
