Change of Course?

[Joseph Lisee]

I stumbled upon this project after spending about 1.5 hours (never saw the CMake code before) figuring out if I could easily get CMake to run a python version of a CMakeLists file.  Turns out my plans were very similar to what was done with this Lua effort.  A main difference was I was planning on putting a nice pythonic wrapper interface on all those cmake commands instead of sticking to all that string passing.

I did realize something else during my investigation, CMake already has a decent API for for plugins, and you could make a plugin command that allows you to run CMakeLists.txt files in python.  The usage would be something like that:

CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project(testpython)
load_command(RunPython ${CMAKE_SOURCE_DIR}/plugins)
runpython(CmakeLists.py)

CMakeLists.py:
cm.add_executable("hello", "hello.cpp")

Of course this doesn't have the sort of tight integration to make using another language easy.

My change of course would be stop trying to get another language into CMake and to instead get the hooks put into CMake such that you can easily use whatever language you please.  These hooks would be a simple extension of the existing plugin system with functions for handling things like command registration, and supplying the file ending for your language.  The last change would be a some kind of command line option that would get the plugin loaded before CMake tries to process the CMakeLists.txt.

I know the CMake developers really don't want to maintain multiple languages, but from what I have looked at so little of the code would need to change to add this multi-language capability it would be easy to maintain.  Then its just up to each group of language lovers to maintain there plugins.

With the plugin approach people don't have to build a custom version of CMake to try out lua, or python, or ruby.  This makes it much easier for users to see if a "real" language is actually a better choice for them.  Its also so easy to do, that stubborn users like myself would stop bugging people, build there python interface and be happy using it.

-Joseph Lisee

[Ryan C. Gordon]

> My change of course would be stop trying to get another language into
> CMake and to instead get the hooks put into CMake such that you can
> easily use whatever language you please.

In a perfect world (that is, in a world where someone takes the time to
build everything I idly think up), I would probably not integrate Lua
into CMake, or build hooks into it, but rather rip it into two pieces:
libcmake (a shared library that exposes all the functions you could call
in CMakeLists.txt, and the makefile/visualstudio/xcode/etc backends),
and cmake (a scripting language interpreter for the current
CMakeLists.txt syntax that calls into libcmake).

Then I'd expose the libcmake functions through SWIG bindings or whatever
and just tell people to use whatever language they like for their build
system. As long as the language can call C functions in a shared
library, it can be used. Someone would have to figure out what to do
with all the existing macros in /usr/share/cmake*/Modules...possibly we
just build the existing syntax into libcmake and the cmake "interpreter"
becomes a one-page C program.

But, for now, I certainly don't have time to work on it. But I'd be
interested to see if it could work.

--ryan.

[Joseph Lisee]

On Wed, Jun 24, 2009 at 10:34 PM, Ryan C. Gordon <icc...@icculus.org> wrote:

> My change of course would be stop trying to get another language into
> CMake and to instead get the hooks put into CMake such that you can
> easily use whatever language you please.

In a perfect world (that is, in a world where someone takes the time to
build everything I idly think up), I would probably not integrate Lua
into CMake, or build hooks into it, but rather rip it into two pieces:
libcmake (a shared library that exposes all the functions you could call
in CMakeLists.txt, and the makefile/visualstudio/xcode/etc backends),
and cmake (a scripting language interpreter for the current
CMakeLists.txt syntax that calls into libcmake).

Right that's in a perfect world, but the CMake developers don't want to go through the design and coding efforts that will functionally leave them right where they started.  There are probably a number of benifits to seperating them out from a maintence standpoint, but you really can't know till you do it.   I feel like what are thinking is that the above idea is the "better" to the "good enough".  The pragmatic developer picks the "good enough" and moves on to other things.

But, for now, I certainly don't have time to work on it. But I'd be
interested to see if it could work.

My point was to offer a low impact solution to getting multiple language "front ends" into CMake.  Its not the nice pretty solution, but its the practical one if you want something has a good chance of actually getting excepted upstream (at least in my opinion).

What I was trying to figure out was if anyone thinks implementing and submitting such a solution is worth it?  I figure its the only chance to actually multi-language support into CMake.  If it turns out successful, mabye the libcmake effort will take off as well.

-Joe L.

[Peter Kümmel]

This idea was already discussed and rejected by Kitware here:

http://www.mail-archive.com/cm...@cmake.org/msg12092.html

Peter

[Joseph Lisee]

Well this is a super old thread, but yes I believe I was aware of that discussion at the time. The major difference is you are proposing tons of work for the CMake devs in order to get a nice clean multilanguage CMake.  That is why I made this post, because my method just needs a small easy to maintain patch to CMake and then 3rd parties could maintain CMake for python, ruby, lue etc. as plugins.  There fragmentation arguments are valid still valid, but hold less weight because only people who really dislike the CMake language would ever here about the custom language plugins.

I still like the idea, and if I ever have to write a giant build system in CMake again I might just give  it a try.

-Joe L.

[Peter Kümmel]

On 11.12.2010 17:40, Joseph Lisee wrote:

Hi Joe,

nice to read your reply, I didn't thought I get one, the post was
mention as "just for the records".

I also didn't saw the difference between your and my approach.
But when there is a solution with less work for the cmake guys
maybe we have a chance to get it upstream.

So are you interested in reanimating this project?
I would also spend some time on it.

Peter