On 2008-12-26 22:25-0500 Naram Qashat wrote:
The subject pretty much sums up the question. I'd like to know if it's possible, though. I was trying to get CMake adopted to be used for a project I'm working on, but the response has been mixed. The biggest detractor has been that CMake is required at all times to build, while the old build system was using Autotools and didn't require the users to need Autotools installed beforehand in order to build. It's a combination of that and the amount of space required to build CMake itself (most of our users are using shell hosts that won't provide them CMake) that has given more heavy negative feedback than positive, even though the other advantages CMake gives outweigh Autotools. But this is the biggest disadvantage that is bringing it down.
If you judge CMake and how well it emulates autotools, you have lost the sales job for your software project right there. Instead, you should acknowledge to those you are trying to convince right up front that CMake is a paradigm shift compared to autotools and lots of things will be different. However, and this is the key sales point, many of those differences will be positive. I am sure you have your own list of things you like about CMake, from the developer perspective so I will not add my own list. However, let's look more carefully at the size issue from the user (as opposed to developer) perspective. The "configure" and "libtool" shell scripts that must be used in the autotoolized approach tend to be extremely large scripts. I just checked this with some historical data for the PLplot project (before we converted it to CMake), and the configure script was 1.2M and the libtool script weighed in at 220K. Those numbers are to be compared with the cmake executable size (2.7M). Thus, if your project's numbers are close to those historical PLplot figures, it looks like the size issue is a win for autotools, but not an enormous win (roughly 1.3M in our case). However, are your users really so starved for disk space that an extra 1.3M is going to matter? Since they are building your software that means they already have a development suite installed as well as some shell such as bash, and compared to the size of all those OS components, an extra 1.3M is pretty negligible. It appears to me that the size issue is likely spurious so probably what really concerns your opponents is the necessity for each of your users to build CMake (assuming they don't have access to a Linux distribution like Ubuntu where CMake is available in binary form). That is a legitimate concern. However, it should be pointed out that the cost of autotools using shell scripts is huge in terms of speed. It is well known that cmake configuration generally takes far less time than the configure shell script, but that makes sense because cmake is a specialized executable while configure is an enormous and complicated shell script. Also, libtool is a pretty complicated script also, and that is executed every time compiler and/or link options are needed at build time which adds some unwelcome build latency. So the question for users really boils down to whether they are willing to pay the (ideally one-time) cost of a CMake build in order to gain access to the speed advantage when building your project? With a bit of care a CMake-based build system for a given project can coexist with an autotools-based build system. So when we introduced a CMake-based build system for PLplot we retained the autotools one for some time but did not develop it further. Thus, users who wanted access to new PLplot features or quicker builds naturally started using the CMake-based build system. Under these circumstances we never once got a complaint about the shift to CMake, and for our latest releases we have dropped autotools altogether (again without any user complaint). So your aim should be to introduce a CMake-based build system into your project that peacefully coexists with your current autotools-based build system and which provides a faster alternative to that system for those users who are willing to build CMake. Surely your opponents could not object to that approach? The required extra CMakeLists.txt files are small and size is probably a spurious issue in any case. Then let nature take its course and a year or two later you will find that only the CMake-based build system is being used, and you can then clean out all the autotools cruft from your source distribution. :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
