From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Page <dpage(at)pgadmin(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: About CMake |
Date: | 2008-12-29 23:01:35 |
Message-ID: | 495956CF.30306@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Gregory Stark wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>
>> Jonah H. Harris wrote:
>>> On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> But of course those are just as straightforward in autoconf. It's
>>>> the not-straightforward stuff that's going to be a PITA to translate.
>>> As much as I dislike autotools, I really despise CMake; it's a nasty
>>> piece of work and I hope we don't switch to it. Though, as I must've
>>> missed it, what's the main complaint with the current build system?
>> Impossible to use autoconf on Win32.
>
> I don't think that's actually it. We used to use autoconf when we used cygwin
> to build, didn't we? And there are other tools that use autoconf on windows.
No. We've never used cygwin for the win32 build, only for the cygwin build.
We've used mingw, which is completely different. But it's still a major
PITA to set up, and binaries produced using it aren't compatible with
windows tracing and debugging tools for example.
Heck, mingw is barely compatible with itself some days :-)
> We could use autoconf on win32 using cygwin utilities for things like sh and
> awk. Just because we use those tools doesn't mean we have to use a cygwin
> compiler or linker to actually do the build.
It does. autoconf is not compatible with MSVC. We did investigate that
before we shipped.
> And we could always ship the preconfigured pg_config.h from a normal Windows
> machine with cygwin installed since they're all the same (in theory).
That's basically what we do now (except it's not cygwin, and it's only
"almost mingw" since MSVC and mingw aren't entirely compatible)
> I think it has more to do with the build-time tools. We have Makefile rules
> that use awk or sed in them and those wouldn't work unless you have cygwin
> installed when building. And in any case we want to use MSVC project files and
Even so, "unix style" Makefiles don't work with MSVC. The compiler is
too different from all unix style compilers. We did try this...
But yes, the build time stuff is what's hard. If you look at the msvc
build stuff now it's mostly parsing our Makefiles and generating the
output. The autoconf stuff is a lot easier since we only target a single
platform.
> MSVC's make-equivalent to actually drive the build which kind of rules out
> using the Makefile rules as-is.
The point is that cmake generates both makefiles and project files.
What we *could* do is define our own "metaformat" for the build stuff,
and use that to *generate* our own makefiles. That would then be instead
of using the CMake format, we use our own perlscript or something. Some
projects do this - I think OpenSSL for example.
That way we'd have a single master, and keep using autoconf for what it
does.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-30 03:59:19 | pgsql: Fix oversight in ALTER TABLE ENABLE/DISABLE RULE patch: the new |
Previous Message | Andrew Dunstan | 2008-12-29 22:59:11 | Re: About CMake |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-29 23:13:00 | Re: Windowing Function Patch Review -> Standard Conformance |
Previous Message | Andrew Dunstan | 2008-12-29 22:59:11 | Re: About CMake |