[CMake] improve the CMake language?

[David Cole]

Existing CMake "plugin" :
EXECUTE_PROCESS(COMMAND tclsh "$ENV{HOME}/myTclScript.tcl" OUTPUT_VARIABLE
ov RESULT_VARIABLE rv)

You are responsible for making sure tclsh is callable for your project's
users...
Similarly for python, ruby, perl, shell script, or *whatever*
Or, if you want it done as part of the build, same command line but with
ADD_CUSTOM_COMMAND...

Because there is such diversity out there and people have so many varied
opinions of which language would be ideal to use, CMake *already provides*
the ability to shell out to any script processor you would like.

CMake's -P scripting ability is actually quite powerful for what it is right
now, though with its own quirks, and incremental improvements are bound to
come over time, but...

...in the mean time, just use whatever scripting languauge you want. Make
macros that demonstrate how to run scripts at configure time and at build
time with your favorite script processor and submit them to the Wiki for
others to benefit from if you feel so inclined.


2 cents,
David


On 11/2/07, Eric Noulard <eric.noulard at gmail.com> wrote:
>
> 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
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20071102/2cff406f/attachment.htm