[CMake] OO and/or IDEs

[Alan W. Irwin]

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
__________________________