[CMake] Is CMake powerful enough?

[Brandon Van Every]

On 6/8/07, Oliver Kullmann <O.Kullmann at swansea.ac.uk> wrote:
> Alan W. Irwin wrote:
>
> > I always run cmake with a separate build tree so one set of
> > terminal windows is open in various sub-directories of the source tree and
> > one set in various sub-directories of the build tree, and I now think of
> > this as the natural way to develop.
>
> I can hardly imagine this to be practical in my case:
>
> 1. There are really quite a few directories, all nested ("recursively"),
> and always mirroring the directory movements would be a pain (and
> error prone).

Are you sure that keeping multiple console or shell windows open and
switching between them is really that hard?  I mean, I used to be
worried that the Darcs revision control system didn't have any slick
integration with Visual Studio, but then I learned how to do stuff on
the command line and it wasn't a big deal.

> 2. And then there is the concept of an "active library", which roughly
> says that the users of the library have *all the power* the developer
> have --- and since the users very likely want it convenient, also
> the developer needs to have it very convenient ;-)

Well part of the issue here is whether you want to engineer your own
build system from scratch, or leverage an extant build system that is
industrially proven.  The user is going to have to learn something,
whether it's your homebrew or CMake.  Can you produce a build system
that is so simple and elegant, that it costs you significantly less to
document, extend, and maintain it, than it would if you outsourced
those jobs to CMake?  I am doubtful, especially considering the size
of the CMake community.

Another issue is whether the users actually need this.  You may think
they need this, and from a contribution standpoint, you may want them
to need this.  But will they actually do it?  Most users just use
stuff, for some other purpose.  They don't put tons of their time into
improving the infrastructure itself.

I have experience with that sort of thing in both the Chicken Scheme
and CMake open source projects.  I find the politics of it very
challenging.  I'm not convinced the underlying build technology is the
lynchpin of user contributions.  I think effective documentation,
responsiveness to user problems, ease of submission to a bug tracker,
and ease of getting patches accepted are far more important issues.

Really the only magic I have here is leading by example.

> > Myself, I've gotten very irritated when looking at functional
> > programming languages, only to see build systems based on untyped
> > shells using incredibly error prone system tools.
>
> It's also my experience that functional programming in some respect
> is quite advanced, and in some others quite backward.

Agreed.  I was looking for better assembly code technology, and it
turns out that very few people in the FP crowd actually care about
that.  They tend to have ok tools on Unix and substandard broken
not-very-well-supported tools on Windows.  I've come to the world view
that tools and industrial support are far more important than the
elegance of a programming language.  It was by pain and pulling teeth,
I certainly didn't start with that world view.  Frankly I went back to
programming in C++ recently.  I may yet pull Scheme out of my bag of
tricks someday, but right now my problems are mainly dominated by
mundane OS interfacing issues.

I think in the real world, Java and C# will continue to steal from FP
until the industrial motive to use "better languages" is gone.  Even
C++ has a lot of FP stuff in the Boost library.

> One could say, that in my case one should just use of infrastructure
> what's easiest, but I don't believe in wasting my time with using
> inferior things, and I got interested in the idea of "active libraries"
> (which (for me) comes from the field of generative programming (in C++)),
> so that I want to create a complete novel *system*, not just another
> library.

Well, I've contemplated an integrated compiler, editor, build system,
program database, and dynamic linker to end this silliness we've been
doing since the 1970s.  But this is research and I don't have the
means to pursue it.  At some point you have to decide what you've got
funding for, and whether the funding is going to go away if you don't
show results.  In my case the price of failure is losing the roof over
my head, I don't have any kind of academic position or other funding
body to support me.  I've come close to it a couple of times now,
pursuing better CMake build systems when I should have been out
scaring up some paying work, and it gets old.  Right now, things have
to make me money if I'm going to spend significant time on them,
that's just the position I'm in.

I wish it were strategic to pursue the uber program-edit-build-link
system, but it isn't.  It'll be pure R&D for another 20 years.

> (So that I hold the
> believe that with better build system we will also get better
> "SAT solving".)

Possibly.  But I'd tackle that agenda incrementally.  Otherwise the
risk of getting nothing useful done is too great.


Cheers,
Bran