On 2017-02-10 12:07:15 -0500, Robert Haas wrote:
> On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
> > On 1/30/17 1:28 AM, Andres Freund wrote:
> >> Given that fact, I just don't buy why it's a good idea to not also
> >> replace autoconf initially.
> >
> > Well, I find it a bit scary. If you do the big switch all at once, then
> > you will have to dedicate the following 3 months to fixing complaints
> > from developers and build farmers.
>
> I agree with that. I think replacing the Windows build system first
> and then the non-Windows build system later is a better plan than
> replacing both at the same time.
Obviously I disagree ;)
But I'm more replying because of:
> 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.
Greetings,
Andres Freund