Re: [HACKERS] WIP: About CMake v2

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