> The more and more I work with cmake, the more it feels like there are two > (or more) distinct tools rolled into one... > > the "front end" is a piece of software that interprets CMakeLists.txt > files, > and drives a "back end". The back end is the stuff that actually > generates > compiler specific project files (makefiles, whatever). > > I'm wondering if anyone feels the same way? > > Specifically I would be interested in using/writing a ruby front end for > writing my build files in. This would give me powerful cross > platform constructs for interacting with the file system (FILE()), > list/set/hash manipulation, etc, and would give me a back end set of > calls to drive the build file generation. The cost of course would be > (for me as a user) having to have both ruby and cmake installed. > > The present front end seems like it will always be useful to keep > cmake a tight self contained piece of software... My (very under > cooked) thoughts are that a code restructuring could take place that > would expose hooks into a generation engine that could then be exposed > to other languages (via SWIG, or manually, or whatever). The existing > "front end" would use that code. > > Is anyone interested in this kinda thinking? Is there any previous work > in this direction?
Well if CMake is architected correctly then there should be a nice line between the language parsing and execution. And it is close to that but not quite there :) I did briefly consider incorporating Lua into an experimental CMake just to see what the list files looked like and how clean the integration would be. But my intent was more curiosity and to clean up the architecture of CMake than to seriously put forth an alternate language binding. On the good side I was able to CMakeify LUA in just a couple minutes. _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
