Re: WIP: About CMake v2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: About CMake v2
Date
Msg-id 10683.1441122365@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: About CMake v2  (Andres Freund <andres@anarazel.de>)
Responses Re: WIP: About CMake v2
Re: WIP: About CMake v2
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2015-09-01 10:32:39 -0400, Noah Misch wrote:
>> 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.

> I don't buy this.

Me either.  I think the odds would be better than 50-50 that we'd never
get past that stage, and we'd be left with a situation where we've still
got two build systems, only one of them is cmake not hand-rolled perl.

Now, maybe that's still an improvement over what we've got, but the
argument is significantly harder to make.  We'd have bought into all of
cmake's disadvantages (whatever they prove to be) but we'd be missing
the main claimed advantage.  Also, while src/tools/msvc certainly has
got limitations, it does get a fair amount of its info out of the
Makefiles; having to change it when you add a file or whatever is the
exception not the rule.  A separate cmake build system would certainly
require maintenance *every* time we touch the Makefiles.

I would actually suggest that the cmake conversion would be better off
to ignore src/tools/msvc altogether to begin with.  Build something that
can handle, say, the Linux build, and then stop and evaluate.  If that
looks good then start extending to other platforms.  If cmake is as nifty
as some folks claim, you might already have an 80%-working Windows build
at that point.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [PROPOSAL] Effective storage of duplicates in B-tree index.
Next
From: Teodor Sigaev
Date:
Subject: Re: WIP: Access method extendability