[CMake] improve the CMake language?

Eric Noulard eric.noulard at gmail.com
Fri Nov 2 06:04:10 EDT 2007


Hi all,

I'm interested in the idea of a "more powerful" CMake scripting.
I'm convinced I lack powerful scripting sometimes (may be many times)
but my opinion is it's not CMake's script job.

2007/11/2, Sanchez, Juan <juan.sanchez at amd.com>:
>
>  Tcl is a simple language, and is well understood.  It has already been
> ported to about every platform out there.  You don't need QT or wxWidgets,
> because the Tk extensions of it already work.

I did some Tcl, Perl and Python.
Tcl syntax is really awkward at first sight.
You get used to it but not as fast Python.
I did some 7 years of Fortran programming (mostly F77 and F90)
then 10+ years of C++.
Fortran is far better than C++ for many things.
The converse is true too :=)
I used Java for 4+ years (all thoses years are overlapping :=)
it was really pleased using it for cross platform GUI.
And I was really disappointed because the java I  used
was lacking generics such that I need to cast here and there when
using container.

I hope I've already put you on the road of
"there is no FAR better language than other".

Personally if I were to extend or re-implement CMake
scripts I'll do it in Python because I _currently_
find it far more powerful than Tcl and pretty widespread too.
(I had even looked at SCons for this reason before using CMake).

But the fact is I don't think I _NEED_ a python
implementation of CMake but may be I would like
a "Python plugin" (or Tcl or Ruby or ...) for CMake.

This way we can keep the CMake scripting language
small and bug free (someday) and take the "Python plugin"
escape door when needed.

>  Many features in the CMake language don't really work the way people
> expect, or are not documented, or both.

Documentation is not as good as it should be
but re-implementing something (either TCL, Python, Perl)
won't make the documentation better.

I know you'll inherit a clean syntax definition
(iff you ever chose python :=) but you won't get
the "up to date" documentation for your freshly
implemented functions.

As for bug I'm sure you know that fresh new software
usually have many more bugs than old one.

>  If anyone would like to fork cmake with me, I'm game.
>
>  Features:
>
>  Tcl frontend featuring modern dynamic language constructs and consistent
> syntax.
>
>  C pre-processor based dependency scanner
>
>  Accurate and up to date documentation
>
>  Focus on getting build system that works, because all of the language
> constructs have already been written.
>
>  Developers who are not hostile to ideas concerning improvements to the
> language.

I am convinced of the usefullness of improvement of the language
but I'm not convinced that a fork is the way to go.

What would you think of

CMAKE_LOAD_PLUGIN(TCL)

CMAKE_TCL(IN_VAR a
                    IN_VAR b
                    OUT_VAR g
                    OUT_VAR h
                    SCRIPT_STRING "<any tcl code>")

or

CMAKE_TCL(IN_VAR a
                    IN_VAR b
                    OUT_VAR g
                    OUT_VAR h
                    SCRIPT_FILE "/path/to/tcl_script.tcl")

In both cases you can run Tcl code from within CMake scripts
you give IN_VAR and you get OUT_VAR.

All this is my own opinion though :=)
-- 
Erk


More information about the CMake mailing list