lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Feb 12, 2008 10:10 PM, KHMan <> wrote:
> Brandon Van Every wrote:
> >
> > [snip]
> > I've been looking around in various places to see if the results
> > exist.  Ruby Rake and its derivatives are probably the next port of
> > call.
> You are going about testing this theory the wrong way. As far as
> list postings go, no Lua-based build tool that I know of is making
> a serious push to try to make a splash in the market. Acquiring
> the knowledge and experience to support multiple versions of
> multiple platforms is non-trivial. Thus, it is impossible or
> invalid to compare success or market wins or adoption rates,
> because there are none at the maturity or support level of CMake.
> So we are left with comparing syntax and existing (in CMake) or
> potential (in Lua build tools) features, et cetera. This involve
> mostly personal opinions, so take them with a big pinch of salt.

The search for evidence of "better programming paradigms" in large
scale build systems is not limited to Lua.    SCons (Python) and Rake
(Ruby) are appropriate things to study, for instance.  Maven (Java)
has some higher level paradigms about supporting the build over the
software's lifecycle, but I've really not read up on what they're on

> Another 20 years down the road,
> there will still be an autoconf demographic.

I think the only reason that will remain true, is the inherent
stubbornness of the Free Software Foundation.  They'll be the last
bastion of autoconf.  Maybe even they will have to adapt, if the rest
of the Open Source universe decides that cross-platform build support
is more important than single platform Unix religion.  But I won't
attempt to predict the relationship between Unix, Windows, and Open
Source 20 years from now.

> Makefiles will still be around.

Well, Cobol is still around.  Doesn't make it a popular language for
modern work.

> Take Tcl for example. IIRC it
> started as a glorified batch file and was popular with hardware
> synthesis software, and it's still doing fine, but no one can
> really argue that Tcl syntax is very well designed or elegant.

Define "fine."  I haven't seen evidence of anyone liking Tcl nowadays
or using it for new projects.  I think it has lost the scripting wars
for the most part.

> Perhaps if Brandon can get a sample CMake-to-Lua translator
> working (just a front end),

I'm not volunteering for such a mission.  I don't need CMake to "go
Lua."  I *do* think it is advisable for CMake to be strategically
appraised of potential and actual competitors.  Perhaps nobody does
anything better than CMake right now, and all CMake needs is a good
marketing campaign to address perceived needs like
"ultra-configurability."  I make no assumptions.  I simply
investigate, and I measure the truth of technological claims by what I
see getting done in the real world.  I also knock down silly reasons
why a CMake to Lua migration *can't* be done.  For instance, "Oh we'll
have to support 2 languages forever" was presented as a reason.  It's
entirely possible to write automatic translators, I've been doing it
for Autoconf + GMake, so what's another language?  Sure there would be
a migration period, and there would have to be a firm commitment to
migration.  But the point is it's possible, there's no inherent
dealbreaker.  I point out what is possible.  I also research what is
*worthwhile*, and I don't see the case for Lua over CMake script yet.
Kitware's position is they'll just keep improving CMake script.  Their
current approach doesn't look like it'll fail to work anytime soon,
and they haven't even tried to market or whitepaper the darned thing.

Brandon Van Every