Re: Premake vs. CMake

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

On Feb 3, 2008 9:48 AM, Thiago Bastos <tabastos@gmail.com> wrote:
>
> Please enlighten me if the following 'case' can be easily implemented with
> CMake.  [stuff]

Doesn't sound particularly challenging to me.  You'd need to
find_program to identify your choice of download tool as CMake doesn't
have inherent support for this.  You'd have a pile of
option(enable_foo "This is foo" ON) settings to control the
integration of optional components, and you'd bracket build targets
with if(enable_foo) .. else(enable_foo) .. endif(enable_foo).  Build
targets would have add_custom_command for the download, and their
results would feed add_executable and add_library.  Stick your IDL
processing and install packaging stuff in there as you need it; you
could use CPack.

I don't see anything about the Lua language capabilities that would
make this easier or uniquely doable.  The job is about specifying
dependencies.  CMake is a system for doing that; Lua isn't.

> This is more or less what I've accomplished with SCons (which 'has' a 'full
> blown' scripting language). The advantage of 'full blown' scripting
> languages, if used well, is that you can extend the build tool from within
> an application's build script, and so you don't have to write plugins or
> auxiliary tools to do advanced stuff.

But since you can write C++ plugin modules for CMake, and access
auxiliary tools using add_custom_command, this is merely aesthetics.
Why do I want to write a download tool?  There are plenty out there I
can just use.  If I do write a download tool, why do I want to make it
inaccessible from a command prompt?


Cheers,
Brandon Van Every