Hi Brandon,
On Tue, Mar 4, 2008 at 7:52 AM, Fernando Cacciola
<[EMAIL PROTECTED]> wrote:
>
> Nutshell: is it strategically a good idea to implement Lua support for
> CMake?
>
> - CMake script must be maintained indefinitely for a small percentage
> of users no matter what the migration strategy
BTW, this point is intended to mean that CMake script must always be
supported, even under the most wildly optimistic migration strategy.
One can debate how many CMake script users will have to be supported
indefinitely in practice, but there will always be some. We can add
languages, but we can't really take them away, not without a fork of
the CMake code and community.
Right, that's a good point. Backward compatibility is always a pain, but is
unavoidable.
OK, time to see what Lua is...
Or maybe see what Python is. Just because SCons uses Python 1.5 and
Waf uses Python 2.3, doesn't mean CMake couldn't use it.
The Python
license is fine, it's just slower and not as easy to embed as Lua.
What if Python finally speeds up and Jython goes somewhere? An
article that appeared today:
"Sun hires Python pros in dynamic languages push"
http://www.news.com/8301-10784_3-9884267-7.html?tag=head
I know Python and Ruby. I **love** both and I would have been so happy if
CMake were bult on top of any of them.
I like Ruby a bit better, but just because, so either one is fine with me.
> - too much programmability may cause people to treat CMake as more of
> a library or build component, rather than a standard end user tool
>
People always find the way to shoot themselves in the foot. I say don't
worry about that and trust the programmer.
If I had a reason to be confident that multiple languages could be
used seamlessly with equal engineering quality, maybe it wouldn't be
so insane.
I don't see any need to support multiple languages.
IMO, at most one should be adopted and sticked too.
Last night I thought about what the OO version of CMake
would look like, for marketing not technical reasons. Why not
target.add_dep(dep1 dep2 dep3 ...) ? The swizzle of transforming
command(object ...) to object.command(...) is straightforward.
But this is just syntax, not OO.
I mean, method(object) is just as OO as object << method or object.method
or whatever notation you choose.
Real OO is in the concepts, not syntax.
A way to see the OO in CMake is by focusing on properties since these are
already object-oriented.
Mainstream programmers probably would be more comfortable with
object.keyword(...) to set some state.
I for one am not interested in making mainstream programmers more
confortable but in improving the technical quality of CMake. Good
programmers can appreciate any language provided is well tought out. Python
and Ruby are not just popular, they are great (Java is even more popular and
it sucks).
A lot of the CMake command set
is well defined, field proven, and stable. I don't think anyone would
have a problem mentally translating back and forth, the commands of
the CMake interface that are actually crystal clear.
Which is *the* great thing about CMake. It's high-level focus, but you can
be high-level with any programming paradigm.
It's things like
separate_arguments() that need to be put to death, with type safety
and so forth. I suppose that's a liability of language choice: not
all languages are equally type safe.
At that, Python and Ruby excel.
Still, all of this suggests a
Virtual Machine approach to CMake. The open source universe certainly
clamors for it, so if it could be done to a high level of engineering
quality, maybe it is not so stupid.
It would be very complex VM since the actual machinery is the C++ system
underneath.
(commands map directly to C++ objects). Not that this is a bad thing, but
ity wouldn't be a conventional virtual machine.
This is an important distinction since most other build systems out there
are entirely script based (or almost so). The CMake scripting language OTOH
is really just a wrapper to the underlying C++ system. From that POV,
adopting other languag(s) seems simpler since the real stuff keeps being
implemented in the C++ core.
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
