Re: Premake vs. CMake

["Brandon Van Every" <bvanevery@...>]

On Feb 1, 2008 4:03 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
>
> The point is -- may be it is better to have two excellent tools for
> each side of project size scale than one single average tool 'that
> fits them all'?

But I've yet to see any evidence that "fullblown" scripting languages
have any advantages, other than people's initial comfort level.  I
keep looking for such evidence, but I haven't seen it.  I don't think
small-to-medium projects are going to provide the evidence.  If the
build isn't that large, any approach would work.  I'm more interested
in whether "fullblown" scripting languages provide advantages for
large projects.

> Also I strongly believe that Lua is quite capable to serve
> as an efficient solution for a build tool (not necessary premake),
> targeted at huge projects. Effective in terms of speed, reliability
> and usability and so on.

CMake script doesn't happen to be a slouch either.  Speed as compared
to Autoconf shell scripting is frequently cited as an advantage.
Usability... well that's why I'm researching.  Some features of CMake
script are likeable, others are a pain.  Lua's programming model has
some advantages and disadvantages.

> It is not that we're afraid to invest time into learning something new
> -- if it is worth it. But general (not related to CMake in particular)
> experience with custom programming languages suggests that they tend
> to be... well, of lower quality (either underdeveloped, or buggy, or
> too singleminded about ways to solve problems etc.).

Yeah but do you really believe that as a build tool, premake is of the
same industrial quality as CMake?  CMake has probably 2 orders of
magnitude more development resources going into it.  So the Lua in
Premake may be great, but I'd worry about the build tool itself if I
had to do something large.  I regard Premake as a low end competitor.
I do the research on other build tools to keep it that way.  I figure
if CMake hasn't conquered the universe, then other tools must be doing
something that people like, or CMake is doing something that people
don't like.

> -- and lowering chances that we
> would be able to do things in the ways comfortable for our specific
> case.

I think this is a recurring theme in build systems.  Everyone thinks
they're a specific case, that no one has run into their build problems
before.

> By the way, there is one more thing that affected our decision --
> extensibility / maintainability of the build tool itself. If we
> stumbled upon a bug or in sudden need of some mandatory  trick build
> system does not have -- we must be able to solve the problem quickly.
> The fact that premake uses familiar technology is a great plus here.

I don't quite get this.  The Premake sources are written in C and C#.
To extend CMake, you either write C++ in the core, or CMake script in
the modules.  I'd expect a similar drill with Premake, with Lua as the
scripting language.  If you want to do anything really fundamental,
you're going to have to write in C or C#, so the use of Lua is only a
partial advantage.  Also, where are the Lua modules?  CMake has tons
of modules to FindOpenGL, FindSDL, FindPNG, etc.  They ship standard
with CMake.  Premake has nothing.  Kinda boring to have to write all
that stuff yourself.


Cheers,
Brandon Van Every