On 2007-12-17 20:30-0500 Brandon Van Every wrote:
When I peruse http://www.ohloh.net/tags/make I notice that most of the Popular! make-like tools have a particular implementation language associated with them. If you want a make written in Java, you use Ant. If you want it in Ruby, you use Rake. If you want it in C/C++, you use either CMake or GNU Autoconf + GMake.
Correction about Autoconf with some additional comments about autotools. Autoconf requires m4 and shell scripting (both of which are exposed to the user), automake requires perl (hidden from the user with the public interface a unique extension of make), libtool is implemented as a giant (and slow!) shell script with a small number of command-line options for that shell script. autotools tries to use the lowest common denominator of all make systems so it will work on any Unix platform rather than the unique capabilities of native make systems such as GNU make. In sum, as virtually everyone on the Linux side of things realizes by now, autotools is a technical mess. BUT autotools were first to market in the Linux world so there are still a large number of Linux projects that continue with autotools. However, my guess based on obvious technical superiority, the possibility of porting to windows (not all Linux projects are like Chicken!), and the huge advertisement the KDE adoption gave to CMake is that the current CMake share of Linux projects is strongly growing at the expense of autotools. Furthermore, it is obvious from traffic on this list that a large and growing number of windows projects are beginning to use CMake as well. Brandon, because of this strong growth, I disagree with your emphasis on the importance of strategic decisions now for CMake. Those were done a long time ago, and people and projects are strongly voting with their feet despite (and this is an extremely important consideration) virtually everybody absolutely hating to change build systems. So long as the CMake developers steer a steady course and don't shoot themselves in the foot with some stupid decision, their strong growth will continue, and as a result I think they we be _the_ major build system in the decades to come. Thus, my own feeling is CMake developers and users can quit worrying about market share since the future is bright indeed on that score almost regardless of what they do. Instead, they should totally concentrate on technical improvements that don't disturb things too much and which make CMake build systems simply easier to design and maintain. I am talking about such things as cross-compiling, module improvements (including standardization), scoping, improved regex, and even Boolean precedence. The first three are already in the CVS version of CMake and the rest have been recently discussed positively on list with at least a chance to get into CVS. In sum, the CMake developers have something they can be proud of, that pride will continue to drive them to make some modest improvements like listed above, and so long as they don't make any irrevocable mistakes in such changes their current large growth rate assures them of world domination for both Linux and windows build systems. :-) Just my $0.02. 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 __________________________ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake