Re: Premake vs. CMake

["E. Wing" <ewmailing@...>]

In CMake's defense, I will argue that CMake's build system generator
is the best out there by far. You only need to look at CMake's native
OS X support for Xcode, Universal Binaries, bundles, and SDKs and
compare it to any other tool to realize how much farther along CMake
is compared to other tools. Nobody else that I'm aware has even tried
to address all these yet. I consider this level of detail reflective
of the quality/maturity of CMake as whole and I dare say you can
extend this level of detail to the other build generators like Visual
Studio or even Makefiles (it's just harder to compare the
nuances/details compared to the yes/no bullet points). It's just the
scripting language that is the detractor and this is where Lua would
come in.


> BTW the new style convention is lowercase for CMake commands.  All
> caps is still used for keywords and CMake defined variables.  I agree
> that it's more readable to have fewer things shouting at you.  Both
> caps and lowercase work for commands though.  I think that has been
> true for quite awhile, and it may have always been true, but the
> documentation was written in all caps so people imitated that.  Now
> the docs are lowercase where they can be.

CMake used to require all capital letters and lowercase was not
supported. I don't think that case-insensitivity got into CMake until
around 2.0.


> I wonder what happens when those resources go away.

I wouldn't expect the CMake resources to go away anymore than the Lua
resources to go away.


>>> I think of Premake like a configure replacement. We have many people
>>> build our project on Windows, Linux, and MacOSX with out really any
>>> complaints.

>> Does it do that in practice...?

> The autotools (configure), for all their insanities, have a very good
> property:  The user interface for non-developers is utterly trivial,
> well known, and Does What's Needed Automatically in a large number of
> cases.

Autoconf/Automake/libtool don't address/port to Visual Studio which is
the 800lb gorilla. They also don't really address Xcode and all the
wonky things Apple needs to do like Universal Binaries. Autotools
doesn't really address users who want to use IDEs. Yes, CMake supports
all this.


>  A lua-based tool would presumably have the
> advantage of simplicity.  Not to mention portability.

Much like Lua only having a single requirement of a C compiler, CMake
only has a single requirement of a C++ compiler (and yes, it even
works with non-standards compliant C++ compilers like Visual Studio
6). CMake embeds any additional libraries it needs so it doesn't have
any other dependencies and is thus very portable. Lua would obviously
be embedded too if included. Kudos to Lua for being so easy to embed,
tiny, and fast to compile.


> Having to ship CMake
> with one's project seems like a major drawback to me,

It's a chicken & egg problem. But Windows doesn't include anything
including Autotools, so it's a wash there. Other platforms won't
include it by default until enough developers start using it. But
(some) developers don't develop until it is standard with the
platform. But CMake is big enough now that most Unixy platforms have
CMake under package management now, so it's less of an issue (but not
eradicated, especially if you need a version newer than what's in
package management).


> Usually when I see the "we prefer premake" sentiment, or some
> such for another build tool, it's a small project.

I would say that CMake is also fine for small projects. The moment you
have to port a program from say gcc/Linux to Windows/Visual Studio
and/or OS X (with all it's native Apple-isms), it pays for itself. I
have wasted way too much time porting somebody's single platform build
system to get a proper build on the other two platforms.


> Aside from emotions there is an economic reason. There is a limited
> amount of such information one can absorb at a given period of time.
> Usually projects are complicated enough for its developers information
> absorbing throughput to be filled to capacitiy. It is always better
> for the commercial project for its developers to spend time absorbing
> information related directly to the project itself than related to
> auxiliary build systems.

I completely agree with this statement. CMake with a Lua scripting
interface could at least help make the opportunity cost seem
significantly lower, particularly if Lua is already being used or
being considered for the future.



Since there are so many Lua users/experts here, I wanted to mention
that one of the CMake authors attempted to embed Lua as an experiment
to see if providing a Lua based interface to the CMake API was even
possible. After 15 hours of work, it turns out that it is. A simple
prototype that binds the CMake API functions to Lua was made
available. It is incomplete though because it doesn't bind the CMake
variable system. Due to various non-technical reasons, it looks like
this experiment will not continue, at least by the official CMake
authors. But if anybody would like to help keep this experiment alive,
volunteers/leaders would be welcome.

You can find information on the experiment here:
http://www.cmake.org/Wiki/CMake:Experiments_With_Lua#Notes


Thanks,
Eric