[CMake] attempt to summarize

[Brandon Van Every]

On Dec 18, 2007 4:08 PM, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
>
> Missing:
> -ant: I think having an ant generator might be nice [...]
>  It would also mean that CMake
> generates ("modern") XML files instead of ("old fashioned") Makefiles.
> -any others ?

If someone wants to do Ant, and they're really really motivated, then
they'll do Ant and I imagine CMake won't refuse their work.

However, I'm not presently convinced that Ant, Maven 2, or XML-based
build systems in general, are strategic.  Although widely deployed,
there are some indications that the Java universe doesn't think
they're so hot after all.  Wiser people have recognized that you
really do need conditional logic to do a build system, and that
hacking conditionals within the constraints of XML is extremely
clunky.  This is the origin of JRake, Raven, and Groovy.  I would
watch these tools, and similar, to see what kind of progress they
make.  If we had a crystal ball, we'd really like to know who's going
to win the "how do you script Java?" wars.  There are many offerings.
No clear winners.

In the same vein I'm thinking it's premature to commit to Lua.  It may
be more important to commit to whatever the Java universe commits to.
Consider, for example, that embedding Ruby and shipping with possibly
4MB of source file bloat, would be acceptable if it emerged as the
clear slam dunk de facto standard for building Java apps.  But that
wouldn't be for several years yet, if ever.  I can't tell whether
Raven is a really important project, or just 2 guys getting a lot of
notoriety because nobody else is doing anything.  Their mailing list
certainly has a lot of crickets chirping.  At some point next year I
imagine we'll see what they're capable of.

The performance differences between Python, Ruby, and Lua may also
change in the next few years.  People have worked on speeding Python
and Ruby up.  Maybe someone will finally succeed?

I think migration technologies in general are worth investing in.
This is a more technologically advanced proposition than hanging one's
hat on Python, Ruby, or Lua and hoping that OO will confer competitive
advantages.  I think the money is tied up in moving from old build
systems to new build systems, and making that job less labor
intensive.  I don't have any thoughts yet on what an ideal migration
technology would look like.  When I look at the Tiobe list of popular
languages http://www.tiobe.com/tpci.htm , none of the top 20 languages
are interesting as a basis for migration technology.  With the
possible exception of Lisp/Scheme.  This says to me that industry
doesn't know how to metaprogram.  I do follow the Microsoft Research
offerings a little bit.  Perhaps they will push one of their languages
into popularity.

I think superior documentation and tutorial technologies are part of
superior migration technologies.  Many things could be done here.
Often not the sort of thing that techies like to do though.

> ------------------------
> CMake features
> ------------------------
>
> better regexps wouldn't hurt

Related: introduce bool type, remove boolean pollution from strings
(Y, N, YES, NO, ON, OFF).  Grabbing small character sequences to mean
TRUE or FALSE is an unclean practice; I've demonstrated the errors it
can introduce.  NOTFOUND is a large character sequence and not so
problematic.

General mechanism for future-looking behaviors, so that we're not
forever stuck with the argument "it'll break backwards compatibility.

> I could create a wiki page "TODO items" so interested people may pick
> something to work on.

Not sure that helps.  Anything I suggested, I can implement.  Others
might get to it faster, and choose to run with it, but if no one else
cares, I certainly will.  I haven't met a lot of open source people
who will just work on any old thing.  Maybe such people exist, and
maybe it's possible to marshal them into various things.  But I think
more is needed than a TODO list, to accomplish that.  Someone has to
actually lead on any given feature.  This is why projects often use a
bug tracker to organize this kind of stuff.  The problem with a bug
tracker is it doesn't tell you at-a-glance what people are working on.
 What we really need is a way to dump that information out of the bug
tracker and display it on a webpage.  Would this be as simple as
defining a particular Mantis view, and then making a wiki page about
using Mantis to examine that view?


Cheers,
Brandon Van Every