-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lloyd Hilaiel wrote: > (probably off topic) > > 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? > I remember someone suggesting Lua as a second language http://public.kitware.com/pipermail/cmake-promote/2005-December/000039.html
- -- Filipe Sousa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEaQepbQdNYqwwwCwRAoqVAKCr8b7b6MpAsXiWrXVOkIf/upEZ2QCgmqtz TV321eQkuBD22/+EmNOjzUg= =ZNIG -----END PGP SIGNATURE----- _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
