Re: [HACKERS] About CMake
Andrew Dunstan wrote: Quite so. CMake outputs MSVC Project files, as I understand it. If you know of another cross-platform build tool that will do that then speak up. I think the wxWidgets team have one, and I think scons has some support for doing that, though I haven't tried that part of scons. The first uses Perl, scons uses Python. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About CMake
Bruce Momjian br...@momjian.us writes: Jonah H. Harris wrote: On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane t...@sss.pgh.pa.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. 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. 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). 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 MSVC's make-equivalent to actually drive the build which kind of rules out using the Makefile rules as-is. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About CMake
Gregory Stark wrote: 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. Making Cygwin a build time requirement for using MSVC is something we seriously wish to avoid. 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). 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 MSVC's make-equivalent to actually drive the build which kind of rules out using the Makefile rules as-is. Quite so. CMake outputs MSVC Project files, as I understand it. If you know of another cross-platform build tool that will do that then speak up. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About CMake
Gregory Stark wrote: Bruce Momjian br...@momjian.us writes: Jonah H. Harris wrote: On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
