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