lua-users home
lua-l archive

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


2008/2/2, Brandon Van Every <bvanevery@gmail.com>:
> I don't have much experience with CMake or Premake, but my first impressions
> are that CMake's script is ugly as hell.

Meaning what, you don't like capital letters?
You don't like some_command(whatever blah blah blah) ?
You don't like typing set(foo blah) instead of foo=blah ?

 All the above arguments plus many others? :-)

>  I was not very impressed by CMake either. It obviously has an edge over
> Premake in terms of maturity and features, but I feel confident that a group
> of 2-3 advanced Lua users could design a superior build tool based on Lua
> (drawing ideas from Premake, SCons, CMake, qmake, etc.). I myself felt
> tempted to start such a project ;-)

Ok, what's the biggest build system you've worked on to date?  And,
what would your business model be?  
 
Well, I've setup a couple of cross-platform continuous-integration systems for C++ projects. With automated testing, doc generation, installer generation, etc. And I've had to develop a couple of custom SCons extensions to handle things such as automatic dependency fetching (since this project has lots of dependencies that must be automatically deployed to the CI build servers whenever they're updated). This build system is reasonably complex, although the project cannot be considered "large". The number of lines or components in a project are not the only source of complexity for a build system. It's much easier to build a project with 1M lines of pure ANSI-C than a medium-sized project with tons of dependencies and tricky requirements.

The world isn't interested in the
work of a few Lua guys who blow off the development and support when
it's no longer amusing.  Critical mass of community and "who's gonna
do the gruntwork" are important long term issues.

Keeping a simple build system in a language familiar to all the developers is probably cheaper than having everyone learn CMake (or worse, SCons/Python, which is much more complex).
If I was to develop such a tool, it would not be to please the world either, but rather myself and maybe others with similar needs, capisce?

> Premake is interesting, but not as extensible or powerful as one would
> expect. It does not support advanced build steps and does not have
> "extensions". For instance, it's unable to build applications that use Qt (a
> must-have, in my case).

CMake does something with Qt.  Not sure what, I just know that there's
an e-mail in my box every day about Qt something or other.  I never
read it because I don't care about Qt.  I think someone has made a Qt
front end for CMake, analogous to the MFC based CMakeSetup.

I know, I considered CMake before adopting SCons. But it looked like I could not adapt CMake to my needs as much as I could do with SCons.

> A mix of
> Premake, CMake and SCons based on Lua would come in handy.

Or you could just contribute to CMake.  I understand the NIH impulse
but I don't subscribe to it.

Too much work, and probably unfeasible due to its established user base. It's not a matter of NIH, but rather practicality. I would only drop the current SCons-based solution for a good reason. Currently the only reason I have is that the build system turned out too complex, and no one in the team knows Python. But I don't think any other build tool that I know would do better than SCons. As far as I can see, CMake cannot easily replace SCons in our case.

-- Thiago