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

[Brandon J. Van Every]

Lloyd Hilaiel wrote:
> All I'm suggesting is that if a library were built as part of the cmake
> build that drew a nice line between language parsing and makefile
> generation, then people like me who constantly want to hack stuff up 
> and try stuff out would be able to do so at a level higher than cmake
> and in a complimentary and cooperative way.  If the existing built-in cmake 
> language parser used that interface it would maintain itself.
>   
The question is whether the code is currently architected for this.  If 
it isn't, then it slows down the CMake team to worry about this, unless 
they desired it for other reasons anyways and were already planning to 
do it.  Assuming the code isn't as nicely compartmentalized as you'd 
like, what are you personally going to do to make it so?  I mean, it's 
one thing to say, "Gee, do a lot / a ton of extra work for me so that I 
can have something nice to hack on."  It's another thing to say, "I'm 
willing to clean up such-and-such a module in such-and-such a way so 
that it's usable for this-or-that purpose.  Will you take my patches if 
I provide them?"  And to be clear, I am not on the CMake team or in any 
way responsible for CMake development.  I just report bugs and plot and 
scheme how to take over the world with CMake.

> This is different than the Lua proposition, because I'm taking a more
> conservative path... I don't know that picking a language and shoving
> it into cmake is the right way to go. 
>   
It isn't... unless it happens to make the CMake team's development 
burdens noticeably easier.  Anything other than that, is work and pain 
for someone else's sake, with no payoff for the majority of us.

I agree that frontend and backend separation makes sense, in principle.  
But I am saying, that is likely a ton of work.  Are you personally 
offering to do a good chunk of that work?


Cheers,
Brandon Van Every