Re: WIP: About CMake v2 - Mailing list pgsql-hackers
| From | Craig Ringer |
|---|---|
| Subject | Re: WIP: About CMake v2 |
| Date | |
| Msg-id | CAMsr+YE9DCU2qYLorU9mM5JUY7FV-h4EKarD7gGzVVNQ5YOChw@mail.gmail.com Whole thread Raw |
| In response to | Re: WIP: About CMake v2 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: WIP: About CMake v2
|
| List | pgsql-hackers |
On 29 August 2015 at 02:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
-- Christopher Browne <cbbrowne@gmail.com> writes:
> (Does CMake run on a VAX 11/780?? :-))
Yeah. I see the two major risks as being:
1. We limit ourselves to platforms that cmake works on.
2. We lose the ability to handle weird special-case tests that are
possible (if not necessarily pleasant) with autoconf/gmake.
I might be overly worried about #2 --- but the impression I have of cmake
is that they've spent lots of time on "make easy cases easy" and maybe not
enough on "make hard cases possible".
I would agree with that, and even go further to "make easy but common cases ugly anyway".
I converted Scribus to CMake years ago as part of porting to Windows. It promised to be a cleaner, nicer build system. It delivered in some ways and was rather ugly in others.
Its configuration/scripting language feels like someone thought "hey, M4 is horrible, lets make sure we keep that it-hurts-so-good feeling in our build system too".
Many prewritten CMake modules fail to follow basic practices that make them work anywhere but where the author wanted/needed. I rewrote pretty much every CMake module I used in the build. That was years ago, mind, but I haven't seen CMake exactly taking over the world since then.
For me CMake saved lots of pain on Windows, but added pain on Linux distros and other platforms where I had to deal more directly with package naming differences, path differences, etc. Maybe I was doing it wrong, or maybe it's improved since.
To me, CMake is just another build system. It has some great features and some truly awful ones, just like most others. It does have the major advantage of working on Windows, but I'd want to know just how much of a hit we were going to take on other platforms. If it breaks m68k netbsd I really, really don't care, but platforms a sane person would use with a modern Pg shouldn't be hurt in the name of making Windows nicer if it doesn't actually gain real functionality.
A possible appeal of CMake to me is that we could more easily support PGXS-like functionality sanely on Windows. It *really* sucks that we don't have anything like that now, and how hard extensions are to build on Windows. OTOH I think it's reasonably practical to use CMake to build a "PGXS-alike" for windows that works with existing unmodified Pg installs of existing versions... so the win isn't big.
Anyway, we won't know unless somebody tries it. There will certainly be
some pluses and some minuses, and we'll have to decide whether the pluses
outweigh the minuses. I don't think we can tell that without a fairly
detailed attempt at making it work.
I agree.
It's pretty much a case of "show us how it looks and we'll decide whether to use your hours and hours of work or throw it away". Don't forget the docs builds... unless of course the CMake conversion is also proposed to come with a full conversion of the docs to a less prehistoric, easier-to-work-with format. In which case you can quadruple the hours you're gambling too.
pgsql-hackers by date: