From: Tor L. <tm...@ik...> - 2009-01-30 12:37:48
|
> How reliable is the "configure" and "make" build model under MinGW? Well, "make" as such is very reliable. It's the configury that generates Makefiles and config.h files etc that usually is tricky. It depends very much on how well the configure.in and Makefile.am files have been written for some particular software package. Unfortunately writing configure.in and Makefile.am files that work well both on Linux, other Unixes, in MSYS with MinGW, and for cross-compilation for instance from Linux (using mingw cross tools) to Win32, is not easy. There are too many liberties left to the developer;) And some developers get some things completely wrong, like having "make install" install headers that #include "config.h". Then there is libtool which has some very spectacular failure modes with interesting error messages. But once you have something that works well, it usually keeps on working well from version to version if only trivial changes, like adding new source files to some executable or library, adding a new library, etc are done. In the GTK+ stack that this thread initially mentioned this holds. (Except that one often has to trick around some libtool misfeatures. The build scripts are included in the developer packages of the GTK+ stack on ftp.gnome.org, in them you can see such tricks.) Some people say CMake is a much better alternative to autotools, libtool and Make. Other say CMake stinks;) And then there are things like SCons that I know nothing about. Yeah, it would be really great if there existed a nice and elegant tool, running on all kinds of Unix, Windows and MacOSX, without any "extra" requirements (like a Bourne-style shell, sed, awk, perl etc) that would supersede all of autofoo, libtool and make. Maybe such a tool even exists. But who could convince most maintainers of Open Source software to switch to this one tool to rule them all? It would be a very big task. Consider that Makefile(,am) files after all can contain arbitrary shell commands in the rules. How should a hypothetical über-tool do things that now use some complex shell command that invokes sed or awk? > The downside is that unless you're quite > expert with Cygwin, the quickest option to getting something built is > usually to wait until one of the experts builds it. The same holds for Win32 and MinGW, to an even higher degree. But even "the experts" have not been experts since birth. It just takes some effort and enthusiasm to learn this stuff... > Sometimes "configure" > and "make" just work "right out of the box" but equally as often, they > don't. Is that also the case for MinGW? Certainly yes. And as Windows is not Unix (unlike Cygwin, which very much tries to look and feel like Unix), much software can't even in theory be compiled for Windows, as the code uses Unix-only APIs, fork() being perhaps the most glaring example. --tml |