Re: [HACKERS] WIP: About CMake v2 - Mailing list pgsql-hackers
From | Craig Ringer |
---|---|
Subject | Re: [HACKERS] WIP: About CMake v2 |
Date | |
Msg-id | CAMsr+YFvUx2DVdKM_75bfn8VtOBG3-YXuwckB7Tp2=i8JsoK6w@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] WIP: About CMake v2 (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
List | pgsql-hackers |
On 11 Feb. 2017 08:42, "Andrew Dunstan" <andrew.dunstan@2ndquadrant.com> wrote:
On 02/10/2017 01:27 PM, Magnus Hagander wrote:
> On Fri, Feb 10, 2017 at 6:07 PM, Robert Haas <robertmhaas@gmail.com> <mailto:robertmhaas@gmail.com>> wrote:
>
> On Mon, Jan 30, 2017 at 10:26 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com > <mailto:peter.eisentraut@Watch this space. There is work being done on building extensions out of2ndquadrant.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.
>
> 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. If nothing
> else, everybody who has to learn the new system either to use it for
> development or because they are doing packaging will have to do some
> amount of extra work as a result of any switch.
>
>
> For me a killer feature would be if/when we can get to a point where
> we can have something pgxs-style on cmake that also works on windows.
>
> Our homemade Windows build system works OK for postgres, and while
> ugly it is as you say well tested by now. But it doesn't do *anything*
> to help people build extensions on Windows.
>
>
tree using CMake on Windows. It's pretty neat, and I'm hoping to demo it
publicly soon. But it's not reliant on CMake in core.
Yeah. In fact it's completely independent of core's build system it and works with any supported Pg, using pg_config for discovery.
We don't need cmake in core for pgxs-like functionality on Windows.
I'd like to use it instead of our Perl windows stuff msbuild stuff in core though. I wonder if it's practical to generate the cmake file lists etc from our Makefiles initialy like we do for the current system, and just replace the MSVC/msbuild project generators with cmake initially.
pgsql-hackers by date: