Date: Tue, 1 Sep 2015 10:32:39 -0400
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
 Andres Freund <andres@anarazel.de>,
 YUriy Zhuravlev <u.zhuravlev@postgrespro.ru>, pgsql-hackers@postgresql.org
Subject: Re: WIP: About CMake v2
Message-ID: <20150901143239.GC2904258@tornado.leadboat.com>
References: <4184974.kkvGJ5GoEX@dinodell>
 <20150828153245.GD2912@alvherre.pgsql>
 <20150828153926.GG4857@alap3.anarazel.de>
 <20150828162849.GE2912@alvherre.pgsql>
 <20150901043331.GA2904638@tornado.leadboat.com>
 <24796.1441082995@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24796.1441082995@sss.pgh.pa.us>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Tue, Sep 01, 2015 at 12:49:55AM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Fri, Aug 28, 2015 at 01:28:49PM -0300, Alvaro Herrera wrote:
> >> If it allows us to get rid of our custom MSVC scripts, it's a huge
> >> benefit, for sure -- that has been a huge pain in the neck since day
> >> one.
> 
> > Moreover, I suggest beginning with a patch that replaces the src/tools/msvc
> > build system with CMake.  One can test almost all Windows configurations using
> > two machines, so author and reviewer can test most everything.  src/tools/msvc
> > has more defects than the GNU make build system, so the minimum-quality
> > acceptable replacement is easier to deliver.  With CMake driving all MSVC
> > builds, it would be much easier to gradually extend to other platforms.
> 
> mmm ... dunno about that plan.  In the first place, you seem to be
> recommending that YUriy incorporate all the deficiencies of src/tools/msvc
> into his first draft and then hope somehow to fix them later.

No, src/tools/msvc is a poor source of implementation ideas.  Implement the
CMake build in idiomatic CMake style.  Write an initial patch sufficient so we
could delete src/tools/msvc in the same patch, and make little or no attempt
to cover other cases.  That's my suggestion.

> In the
> second place, I think that the core problem here involves being sure
> we can still cover all the portability issues that have been laboriously
> hacked into the autoconf/gmake build system over nigh two decades.

I agree that the first patch should demonstrate the CMake programming
environment's sufficiency for open-ended portability adaptations.  I doubt
demonstrating that requires actual porting to more than a platform or two.

> Starting from a build system that was designed to cover exactly one target
> platform, and has never been asked to do anything more than that, doesn't
> sound like a recipe for success there.

Fair point.  Perhaps replace src/tools/msvc completely and build+install on at
least one reasonable GNU/Linux configuration?

A monolithic patch replacing the GNU make build system with a CMake build
system sounds far too hard to write and review; we should expect to maintain
those two build systems in parallel for awhile.  Reconciling the MSVC and GNU
make build systems is a chronic problem today, so it would be a big plus to
have no more than two of MSVC, GNU Make and CMake build systems to maintain.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers