Bill Hoffman escreveu:
That said, an automatic way of running a cmake script at build time as part of a custom_command might be a good feature.

Well, if one of the reasons not to use lua is to avoid calling cmake during build, why do it with a cmake script is a good thing?

I am thinking the lua stuff is pretty much dead at this point (don't get upset :) ), if you see Ken's post here:

I read the whole thread and didn't find any good reason not to adopt lua. There's only the thought that a 'turing complete' language in a build system is a bad think because build systems should be simple. There's also the fact that lua variables aren't cmake variables, and configure_file couldn't work.

For the first reason, I think that simple things should remain simple, and complex things should be made simple. If it's impossible, well, they're complex, and the language should accommodate this fact. If it doesn't, the build system is unsuitable for this application. So it's a Good Thing that cmake use a complete (albeit simple) language, as lua is. Scoped variables aren't the only thing important in a build system. As one said in the thread, if originally scoped variables weren't needed and now they are, maybe something more complex will be needed in the future (OOP? closures?), and if cmake doesn't support it, another build system will. That's not what we want, do we?

For the second reason, there shouldn't be a distinction between lua variables and cmake variables. The former can be accessed by the table returned by the function getfenv(), which holds all variables in the current scope. configure_file could use it.

Sorry to resuscitate this topic. I wasn't around when this was being discussed and don't want to 'kick a dead dog', but I think this issue is important and the discussion was inconclusive. I'm currently using Lua in a 3d panoramic scenery viewer project, and the scenery description is done entirely in lua. So far it's being wonderful and allowed us to do some complex things unimaginable when we were specifying its features.

Ken did add functions to cmake to help with the scope issues. :)

So that's what 'function(...)' is about? In its documentation there's no mention of scoped variables inside functions.

Regards,
rod

_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to