[CMake] cmake ruby bindings (or perl, or python, or ...)

[Brandon J. Van Every]

Lloyd Hilaiel wrote:
> (probably off topic)
>
> The more and more I work with cmake, the more it feels like there are two
> (or more) distinct tools rolled into one...
>
> the "front end" is a piece of software that interprets CMakeLists.txt files,
> and drives a "back end".  The back end is the stuff that actually generates
> compiler specific project files (makefiles, whatever).
>
> I'm wondering if anyone feels the same way?
>
> Specifically I would be interested in using/writing a ruby front end for
> writing my build files in.  This would give me powerful cross
> platform constructs for interacting with the file system (FILE()),
> list/set/hash manipulation, etc, and would give me a back end set of
> calls to drive the build file generation.  
As I do more and more CMake, I'm not yet convinced that there's a value 
add to wrapping it all up in, say, Chicken Scheme.  First that's a huge 
maintenance and coordination burden.  It is exceedingly unlikely to 
remain industrially robust.  Second, whenever I want to ask a question 
of the excellent CMake technical support offered here, nobody's gonna be 
able to help me.  Like it or not, perfect or imperfect language, it is 
the CMAKE language.  There is a lot of value in having everyone work on 
the same thing.  Especially since CMake needs to grow a whole lot and 
gain critical mass, I see the idea of creating front ends for all sorts 
of different languages as exceedingly misguided.

> The cost of course would be
> (for me as a user) having to have both ruby and cmake installed.
>   
Which, as a paradigm, is not terribly useful for people who are looking 
to avoid additional language dependencies.  One selling point of CMake 
over SCons is CMake doesn't ask you to install Python.  All you need is 
a C or C++ compiler, so it's a good tool for migrating to other platforms.

> The present front end seems like it will always be useful to keep
> cmake a tight self contained piece of software...  My (very under
> cooked) thoughts are that a code restructuring could take place that
> would expose hooks into a generation engine that could then be exposed
> to other languages (via SWIG, or manually, or whatever).  The existing
> "front end" would use that code.  
>
> Is anyone interested in this kinda thinking?  Is there any previous work
> in this direction?
>
>   
I'm not the slightest bit interested in hearing about major CMake 
changes that are going to disrupt a winning team.  Leave the internals 
to the CMake guys.  What impresses me the most about CMake, is that when 
I have a bug or feature request, they turn it around rapidly.  A bunch 
of gratuitous compartmentalization is gonna slow them down... unless 
they were already planning on doing that kind of separation anyways.


Cheers,
Brandon Van Every