Disclaimer: My name is attached to the failed CMake/Lua attempt. In principle, I like the idea of what you propose. However, in practice, I think it might be too big and too ambitious.
Here are some quick thoughts I have: - I am in the camp that I do not like the CMake language. And it is often the hardest selling point in my experience, even when you convince them that CMake can do all the cross-platform stuff. (I’m seeing more competition from Gyp these days, but in my limited personal experience, people still have not been able to port highly complex projects to as many target platforms with Gyp, whereas CMake could handle them (and the perceived gains of Gyp disappeared in these complex scenarios)). - Along those lines, part of the problem we seemed to hit was that pure declarative build instructions didn’t hold up well in the complex case. I haven’t done much with Gyp in this manner, but those around me that were trying seemed to hit the wall pretty fast in this. But I have used Ant, and that was a terrible experience for anything that required conditionals. - I would definitely like to see better interoperability with IDEs and tools. I would personally love a simple cross-platform gui project manager that basically allowed you to create targets, add/remove files to be compiled to a target, and set specific compile/link flags on a per-target or per-file basis, sort of like you can do in most IDEs (but if you tried using CMake, your changes get clobbered in the next regeneration…though even better would be able to do this directly in the native IDEs). - I am little concerned about encouraging people to add on any arbitrary language. There are two different problems that this could potentially cause: (1) CMake bloat, (2) Dependency hell - CMake currently can bootstrap itself with just a C++ compiler. That is a good thing. I recently had to get CMake up on a Raspberry Pi. I was fortunate that CMake had few dependencies and was relatively small. (Not counting Qt which was an unmitigated disaster.) - Building other projects using CMake can be painful depending on their dependency chain. While this is not technically CMake’s responsibility, encouraging users to use non-canonical tools can make things a nightmare. CMake has been pretty good about providing fundamental mechanisms you need that work on all platforms. But if users are encouraged to say, “I’ll just use Perl+CPAN or Ruby with these gems”, instead of the standard CMake mechanisms, things get awful quickly. (I finally just reproduced a build of JavaScriptCore for Windows after over a year of trying…it has dependencies on Perl, Python, Ruby, and a bunch of other things I can’t remember, all of which are a terrible pain to get working on Windows.) - In that same line of thought, the reason Lua was a good candidate is because it its tiny which avoids adding bloat, it is pure ANSI C, which means it compiles everywhere CMake already compiles, and it was designed to be an embedded scripting language doing the exact type of things that the current CMake language is asked to do. (Dr. Ken Martin said they were impressed with Lua and would have used it if they had known about it originally.) (By the way, if you haven,t already, I encourage you to read through the old Lua threads circa 2008.) - Incidentally, the Lua table is pretty much the same concept/pre-cursor to JSON in JavaScript. Lua lends it self to both data driven formats as well as custom DSLs pretty well. If Lua were part of the core, you could build a the data-oriented format files without any additional dependencies. - I don’t think the IR will help anything related to the work of adding new languages like Swift. The hard part there is not really the CMake language as much as understanding the overall system design/architecture. No matter what language you pick, that part will always be hard. - Mostly, I’m concerned that this project is too big and ambitious in scope to see completion unless you have funding and a team to drive it. The Lua attempt is a failure, but not for technical reasons. It was a manpower problem. Dr. Ken Martin proved the concept could work in something like 13 hours. But at the time Kitware said they weren’t going to go down that road, so anybody still interested in it was left to make it happen ourselves. We gave it a shot, but none of us really had the time to commit to finish the task, which is much smaller than the one you are proposing. (Granted, we wasted a lot of time trying to bridge CVS (which CMake was still using at the time) with DVCS, so you at least won’t have to worry about constant merge-hell.) -Eric -- 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