Re: Is a modern build system acceptable for older platforms - Mailing list pgsql-hackers

On Tue, May 1, 2018 at 8:12 PM, Yuriy Zhuravlev <stalkerg@gmail.com> wrote:
>> That indeed would be an improvement, but maybe we could fix that specific
>> pain point without having to throw away twenty years worth of work?
>
> Indeed! Only a few thousands of lines of code can generate the whole you
> manually wrote, it's the perfect result!

I don't think that unsubstantiated hyperbole is the right way to
approach the task of convincing the community to adopt the approach
you prefer.  I don't see that any compelling evidence has been
presented that a cmake-based solution would really save thousands of
lines of code.  True, some Perl code that we have now to generate
project files and so forth would go away, but I bet we'll end up
adding new code someplace else because of something-or-other that
doesn't work the same under cmake that it does under the current build
system.  For example:

>> re-invention of portability hacks
> This is the main goal for migrating to cmake - most of hacks cmake takes on
> itself.

Whatever hacks cmake *doesn't* handle will have to be reimplemented in
the cmake framework, and frankly, if history is any indication, we'll
be very lucky indeed if whoever submits the cmake patches is willing
to follow up on the things that break over the days, weeks, months,
years that follow the original commit.  More likely, after the first
few commits, or perhaps the first few months, they'll move on to their
next project and leave it to the committers to sort out whatever stuff
turns out to be broken later.  And very likely, too, they'll not
handle all the changes that are needed on the buildfarm side of
things, and maybe the PGXN side of things if that needs changes, and
they certainly won't update every third-party module in existence to
use the cmake framework.  Accepting a patch to support cmake means
some amount of work and adaptation will need to be done by hundreds of
developers on both the core PostgreSQL code base and various other
code bases, open source and proprietary.  Now it's probably not a lot
of work for any individual person, but it's a lot of work and
disruption over all.  It has to be worth it.

Now, I grant that my ears perked up when Andres mentioned making
parallel make work better.  I don't build on Windows so that issue
doesn't affect me personally -- it's great if it can be made to work
better with or without cmake but I don't have a view on the best way
forward.  But having parallel make work better and more efficiently
and with fewer hard-to-diagnose failure modes would definitely be
nice.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company