Re: Premake vs. CMake

["Alexander Gladysh" <agladysh@...>]

> > 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.

Well, like I said, it was not related to CMake in particular -- it is
just a general feeling of custom-written scripting languages.

> So the Lua in
> Premake may be great, but I'd worry about the build tool itself if I
> had to do something large.

As you pointed out earlier, we have a small-to-medium project, not a large one.

> 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.

All I can say is that in *our* specific case, CMake language was the
showstopper. No matter if it was bad decision or right, or was it well
thought rejection, or mere dislike of lot of all-caps in code. We're
using premake now, and we still comfortable with it, and we do not
have any reasons (yet?) for migrating to any other build system.

If CMake is so good for huge projects -- that is great, we would know
then where to look then time comes to it. But not everyone is
developing a large project -- actually, I think, most of them are
medium and less. ;-)

And for smaller projects "industrial quality" and such things weight
much less -- as long as they are adequate. Comfort is more important.
When one tries to pick one of equally well fitting tools -- he would
pick the tool with the best "initial comfort". And as long as picked
tool remains adequate to his tasks (and vice versa) -- he is not
likely to convert to something else.

One more thing to keep in mind is that such smaller projects usually
may not afford to keep build tools specialist as a separare vacancy --
such man would be idle most of the time. For anyone in team who does
it, maintaining build tools is an (annoying but necessary) recurring
part-time task, distracting them from the main purpose -- writing the
project itself. If this task has a steep learning curve such as
learning a new custom language -- this decreases "initial comfort"
significantly.

> > 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.

We're perfectly content with writing in C and C++ and C# and Lua. We
would probably spend incomfortably more time getting into CMake script
module internals -- since we're not familiar with this custom
language. This fact significantly lowered our "initial comfort"
feeling.

> 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.

You're right. And if we would need many of that modules -- we would
probably came to another decision.

Fortunately we do not need them. Our project's external dependencies
are minimal and we control our build environment under Linux. Actually
we may even dictate exact distro and packages versions and paths.
Windows / Mac are developer-only target platforms for us (not for
industrial grade deployment) -- so things there are even easier from
the point of view of build system. I agree that this may not be the
most representative case -- but anyway. :-)

As I see it, we're discussing two things here.

First -- is premake really "better" than CMake in general?

I agree that CMake is of better "industrial quality", especially (as I
believe your words) for huge projects. Though (if that matter) I still
content with using premake in our projects -- at least until we
stumble against some bad showstopper.

Second -- would CMake benefit from switching from its custom script to Lua?

I say yes, of course -- by reasons I stated above. If you search list
archives, you would even find some recipes on doing such transitions.
Though whether CMake really should perform this transition is a hard
question. I, selfishly, would prefer to see CMake using Lua when (if)
I would have to switch to it. :-)

Alexander.