[CMake] Re: CMake and Lua

[Miguel A. Figueroa-Villanueva]

On Fri, Feb 29, 2008 at 11:09 AM, Bill Hoffman wrote:
> Rodolfo Schulz de Lima wrote:
>
>  > The main issue with CMake script isn't when writing a build script, but
>  > when writing auxiliary stuff, like a more elaborate Find*.cmake. Just
>  > look at FindwxWidgets.cmake to see what I mean...
>  >
>
>  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.
>
>  -Bill

<quote from another related thread>
On Fri, Feb 29, 2008 at 1:22 PM, Rodolfo Schulz de Lima wrote:
> Bill Hoffman escreveu:
>  > Enjoy!
>
>  Wow, that must be a world record... I've mentioned the problem at 10:57
>  (Brazilian Standard Time), and the solution got committed at 14:18
>  (BRST). Guinness anyone?? I which my cable TV customer support were that
>  fast...thanks a lot Bill.

And you all thought Bill was so resistant to change :P

I really think this is the stuff that needs to be addressed and
obviously Bill and the rest of the CMake developers are very willing
to accomodate this. That is, things like relaxing the if/else
constructs, scoping, return, break, lowercase commands, etc. are the
components we need to help facilitate writing more complex stuff in
CMake scripting.

I'm happy with CMake, it works and it's great! I saw the FOSDEM talks
on SCons and CMake on-line and, although I love Python, I really
disliked the SCons syntax. Mainly because it looked too complex for
the simplest of things. That is, it looks like programming rather than
build management... You certainly can't beat:

add_executable(hello hello.cxx)

I wouldn't necessarily object (not that it mattered if I did) to
having two languages supported (e.g., Lua and CMake Script), but
maintaining CMake Script support is a must in my opinion and this is
only necessary if we really can't come up with some more features like
the ones mentioned above to make CMake Scripting a bit better.

However, I think that making a bunch of wrappers to support a variety
of languages is a diservice to the community and it would only help to
fragment the effort, and create all sorts of problems and confusions
that are simply unnecessary.

I'm the author of the all-confusing portion of the FindwxWidgets.cmake
module and that is not a CMake Scripting problem; it is a wxWidgets
problem. If they had structured things better, you wouldn't need all
that inspection and name finding permutations... maybe they need
CMake!!

Finally, as it has been mentioned before, if people want a wrapper to
different languages, why not simply have a CMakeLists.txt:

----
execute_process(run_my_super_fun_language.[exe|sh|etc])
----

The point is that if you need to do complex programming stuff (and
that is a big if for build systems, because you should focus on
simplicity), why not use a programming language and let CMake Script
take care of the build management...

Just my two cents on the matter,
--Miguel