On Mon, 2001-11-12 at 23:10, Damion Shelton wrote: > Is this a criticism of CMake, autoconf, or the standard build practice? Both > CMake and autoconf are open-source, the only distinction is that some > existing projects rely on autoconf (and are therefore not particularly good > candidates for CMake) and that CMake supports Borland and Visual C++ > compilers in addition to GNU. On Unix platforms, you end up saying the same > thing whether or not you've used CMake or autoconf: "make makefile" >
Actually, you'd end up doing './configure [--options]' which creates the Makefiles (to your requirements), then 'make' to build, then 'make install' to install. Some people like me then go on to building RPMs/whatever to take advantage of package management. Maybe Windows users use InstallShield (or whatever, yuk!). OK, so in rough summary, the pros to CMake are that it spits out Borland/Microsoft makefiles, but the cons are that you need to download and install an uncommon build system to generate your makefiles. I don't know how it compares feature-wise with auto* yet. For example if it handles testing for libraries, generating 'install/clean' rules etc yet, as I haven't tried it yet (still downloading!). On the other hand, the pros to automake/autoconf are that it generates a flexible shell script (configure) that identifies your platform, locates and tests required libraries and functions on your system, and generate makefiles. Anyone who uses GNU software will be comfortable with this, and won't require any additional software. The cons are that it doesn't cater well for Windows users (Borland/Microsoft) because they have their own IDEs with their proprietary build configurations. Microsoft users might have some joy with Curt's am2dsp.pl script. So as I see it, the best way forward, which would please both crowds, is to use both systems simultaneously in the various projects, with each crowd maintaining their own system's scripts, making sure required changes are notified to the other crowd via the respective mailling list. This way we're likely to attract/retain a wider range of developers. -- Ross _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
