[CMake] improve the CMake language?

Brandon Van Every bvanevery at gmail.com
Fri Nov 2 13:57:02 EDT 2007


On Nov 2, 2007 1:01 PM, Juan Sanchez <Juan.Sanchez at amd.com> wrote:
>
> Brandon Van Every wrote:
> > On Nov 2, 2007 11:49 AM, Juan E. Sanchez <Juan.Sanchez at amd.com> wrote:
> >> On Fri, 2 Nov 2007, Brandon Van Every wrote:
> >>> To make real improvements in all of those areas, you'd need a lot of
> >>> funding.  What kind of mandate do you have?  There's not much point in
> >>> saying "everything's gonna be better" if you don't have the labor.
> >> This would be a community effort.  I don't have the resources to
> >> strike out on my own.
> >
> > Without a bunch of gold bars at your disposal, I'd say the CMake
> > community isn't going anywhere.  Best to work on compromises within
> > the community rather than sweeping changes.
> >
> >> I like using cmake.  The language is kind of a
> >> bitter pill for people in my organization to swallow.
> >>
> >> The most important item on my proposed feature list is the Tcl
> >> frontend.
> >
> > I know everyone champions their favorite scripting language, but my
> > opinion is, if you go that route you're doomed.  Pick something that
> > programmers consider modern and sexy, or you're never going to get the
> > mindshare.  A key consideration that dominates my own thinking as of
> > late: "Who's gonna pay me to know language X ?"  I went back to C++
> > for this reason.  I'm sorry but whatever its merits, Tcl is not a
> > resume skill nowadays.
>
> Actually Tcl is still quite popular.  Many commercial electronic design
> automation (EDA) companies use Tcl frontends, and EDA is a billion
> dollar industry.  Active State still seems to be doing well peddling
> their supported versions of Tcl as well.
>
> Apart from its consistent syntax, another big selling point is its truly
> free license.
>
> I'd be willing to entertain any other suggestions for scripting
> languages, as long as:
> 1. the syntax is consistent
> 2. the language is not bloated
> 3. the language does not require to much dressing up with parenthesis
> and commas
> 4. the license is BSD-like in nature.

I didn't realize that Ruby is GPLed.  http://www.ruby-lang.org/en/LICENSE.txt
Oh well, so much for embedding Ruby!

Python is essentially BSD + requires that you make brief note of any
changes to Python in derivative works.
http://www.python.org/download/releases/2.5.1/license/  I don't know
how embedded-friendly Python is, particularly in the presence of other
Python installations.  Python regexes are not inherently part of the
syntax; of course, this is true of CMake script as well.  Python
certainly wins popularity contests, and a Python CMake done well would
put SCons out of business + maybe steal their developers.

Lua is MIT licensed.  http://www.lua.org/license.html  Lua is
extremely embedded-friendly, that's its sole reason for existing.  Lua
has brand identity in the world of modern geekdom but is not,
generally speaking, anywhere near as popular as Python or Ruby.  It is
quite popular in the game industry, however, because of a perception
that it's "lean and mean."  I have no idea how beneficial or
detrimental the language syntax is, I've never used it.  Lua's pattern
matching has character classes but not the "|" branching operator.
http://www.lua.org/manual/5.1/manual.html#5.4.1

That's pretty much it for the list of suspects.  I wouldn't hitch the
CMake truck to Perl.

> Note that OOP is more of a detriment than a benefit in my concept of
> "simple" scripting languages.  Obfuscation by encapsulation is not a
> benefit in a flat file architecture.

You can write your non-OOP code however you want, and leave others to
do what they want.  It doesn't matter as far as off-the-shelf
languages go.


Cheers,
Brandon Van Every


More information about the CMake mailing list