[CMake] Re: CMake and Lua
Rodolfo Schulz de Lima
rodolfo at rodsoft.org
Fri Feb 29 10:35:39 EST 2008
Bill Hoffman escreveu:
> Thanks for the feedback. I am wondering if there is something that can
> be done in CMake c++ code to make writing a Find module like wx widgets
> easier. Maybe regular expressions in the find_* commands would help.
> Lots of the verbosity comes from finding different names for libraries
> and paths. I think that has come up on the list or the bug tracker
> recently. The new break and return could clean it up some more, and
> the use of lower case would make it look nicer.
It's tough... I mean, if you follow the cmake script road, you'll have
to 'reinvent the wheel', so to speak, while adding 'return', 'break',
'continue' (it already has scoped variables). The more features you add,
more you turn cmake script in to a full blown script language, but, as I
said, built on a weak and awkward syntax. God knows what this
'Frankenstein' will become.
But, if you decided to go to the Lua way, it's everything there,
semantics, syntax, garbage collector, etc, you just have to worry about
writing primitives that deals with your specific needs, i.e., project
building, that's what you're being paid to do, not to create another
language, there's already a ton of them. The down side is backward
compatibility, which is a valid and important commitment to have.
So, like 99% of engineering problems, you can't have it all, there's
always a restriction. The idea of isolating cmake from the language
parsing isn't to make cmake a tower of babel (like .NET is, for
instance). It's just to have an infrastructure that would enable you to
maintain backwards compatibility with the cmake syntax, which would be
deprecated, and a hopefully new Lua syntax. With a well thought
infrastructure, you wouldn't have problems to maintain 2 languages. Just
correct bugs on the old syntax as they appear, and add features on the
new syntax. If someone want the new feature, well, he should move to Lua.
It's a tough decision that should have been made in the beginning, but
postponing it just make it worst...
Best regards,
rod
More information about the CMake
mailing list