[cmake-developers] CMake alternative language

[Charles Huet]

Thanks for the insight !

I started going towards python because I am more familiar with it, but Lua
seems to be a better fit for CMake now that I think about the constraints
you listed.

The main point I am getting from your mail is that Kitware may not want to
go down this route, even if provided with a working prototype, with the
ability of slow migration by using both CMake script and Lua.

I understand that some users are against such a change (as pointed out in
this very thread) but I'd be willing to contribute time and effort towards
it, if given the assurance it would not be in vain.

>I try really hard to keep my CMake really simple. But unfortunately,
it always gets complicated. Just the fact that platforms and
environments are so different always impacts my CMake scripts. But I’m
very glad that CMake seems to get the job done. Lua would help me
avoid fighting the CMake language, and that would be very welcome. But
I don’t expect the messiness to ever truly go away…that is the
byproduct of systems/environments being so different and ever
changing.

This perfectly sums up what I feel :)

Le jeu. 14 janv. 2016 à 14:46, Eric Wing <ewmailing at gmail.com> a écrit :

> I am hesitant to add more fuel to the fire for this discussion because
> it has been discussed many times before through the years and my sense
> is that this isn’t what Brad is really interested in pursuing. I
> encourage you search the mailing list history.
>
> I’ll try to summarize (off the top of my head) about why Lua (as
> opposed to other languages).
>
> - Lua above all other languages was recommended by me and others
> because it satisfied all the constraints:
>         - It is tiny and can be included with the CMake source and doesn’t
> impact the size of CMake in any significant way
>         - Being 100% ANSI C allows it to go everywhere CMake already goes
> and
> satisfies the requirement that only a C++ compiler is needed to
> bootstrap it.
>         - Lua is a language designed to be embedded, for this very kind of
> purpose.
>         - Lua is sandboxed by default and has a minimal (and optional)
> standard library.
>                 - This means users won’t be encouraged to call all sorts of
> non-portable library calls like with some other languages. CMake can
> control what APIs are exposed addressing those concerns that a full
> programming language may allow too much variance and craziness in the
> community.
>         - Lua’s liberal license is compatible with CMake’s liberal license.
>
> - Lua is one of the cleanest, simplest mainstream languages out there
> and is incredibly easy to learn, yet still supporting a wide range of
> higher-level constructs (functions as first class values, closures,
> proper tail recursion). Documentation and tutorials are readily
> available.
> - Lua’s core data structure is the table, which is a extremely similar
> to JSON (which it happens to also predate), which makes lists and
> declarative data style very easy and natural to do.
> - Lua has proven itself in the video game industry in that C/C++
> developers are comfortable dealing with it (not a syntax shell shock
> to them, say like LISP, or quite frankly CMake)
> - Lua being a full, well designed programming language allows for ways
> to write things which is currently really hard in CMake’s language.
> Additionally, adding features to CMake’s language is hard in that you
> have to think about all the potential side-effects, edge cases, and
> inconsistencies. Lua takes this burden away and how to use everything
> is well known/documented.
>
> - To prove to us that CMake was already too far down the road and
> retrofitting Lua into CMake was not practical, Dr. Ken Martin had a
> CMake/Lua proof of concept working in like 13 hours. (Oops.)
>         - But it was decided that Kitware didn’t want to go down this road.
>
> - We attempted to build off Ken Martin’s experiment to keep it alive,
> but that project essentially failed.
>         - Lack of time, resources, expertise, etc, and this was back in the
> CVS days so keeping up with the mainline was hell since merge tracking
> is pretty much non-existent.
>         - There was one interesting thing implemented showing that both
> existing CMake script and Lua script could co-exist. And I think there
> was even a proof a concept that different language scripts could call
> one another.
>
>
>
> So just on the constraints/requirements issue, I think we convinced
> Brad, that *if* anything should be chosen, it should be Lua, which is
> why Lua is still in his head. And these constraints are still in play.
> I am constantly fighting dependency hell on platforms. It is nice that
> CMake has no external dependencies except a C++ compiler and can
> bootstrap itself. I recently did a bunch of work on a Raspberry Pi and
> I needed to build CMake; no problem. I just tried to build Swift on
> the Pi. I got hit by a bug where the build process pulls in the wrong
> version of Python (2 vs 3) if both exist on the system. What a mess.
> (And a 9+ hour build cycle to retry.) Not to mention the disk space
> problem of needing all these dependencies.
>
> But it sounds like Brad is more interesting in a purely declarative
> replacement for CMake.
> That would be nice for all the editor-assist reasons. Though I’m also
> skeptical of pulling that off (though I hope it can be done in a
> useful way). There are other systems like that, yet, I’m using CMake
> for a reason. I don’t have any real insight on the problem, but I
> recall hacking Ant XML files and just to have a simple conditional
> (if/else) was a huge PITA. And as these things cascade with more
> conditionals, it becomes a major effort. Antidotally, I watched
> several projects try to use Gyp even though there was a CMake
> description already written (albeit, not working for the platforms we
> needed). I watched from the sidelines as those projects failed to get
> Gyp working. I don’t have any insight in why unfortunately. For one
> project though, I did later come in and did get the CMake description
> working.
>
> I try really hard to keep my CMake really simple. But unfortunately,
> it always gets complicated. Just the fact that platforms and
> environments are so different always impacts my CMake scripts. But I’m
> very glad that CMake seems to get the job done. Lua would help me
> avoid fighting the CMake language, and that would be very welcome. But
> I don’t expect the messiness to ever truly go away…that is the
> byproduct of systems/environments being so different and ever
> changing.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160114/224692b5/attachment.html>