Re: Premake vs. CMake

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

On Feb 3, 2008 1:13 AM, Wesley Smith <wesley.hoke@gmail.com> wrote:
>
> 1) Supports multimedia research
> 2) Supports multimedia composition
> 3) Supports distribution of multimedia compositions as self-contained
> applications
>
> These are 3 quite different modalities that the application has to
> work in.  One dictates a certain malleability of the application
> itself.  Another suggests a well designed interface and range of
> libraries for working with multimedia.  The latter requires a well
> designed, flexible, and easy to use deployment/build system.  For this
> project, I'm not assuming users to necessarily be hard core
> programmers who are willing to invest time in learning something like
> CMake sript syntax to support item 3 (this also comes into play in
> implementing item 1).  I do assume people can program and are willing
> to use Lua.

Which sounds crazy, because CMake script is simpler than Lua script.
Sounds like you're biased towards Lua as The One True Scripting
Language, and that you don't want to burden a user with 2 scripting
languages, even if the 2nd language has trivial syntax and supports
the build system in the most efficient possible manner.

> What I need for this project is a serious build system
> that is flexible enough that I can design a high-level API around it
> for end users to, with a few lines of code, write a deployment/build
> script for their compositions and research applications.

A research application is simply
add_executable(myproggy my.c source.c files.c)
target_link_libraries(myproggy -lsomething -lor -lother)
If you're audience is programmers, what's the problem?

> I hope you
> can see the utility of having a language like Lua available within a
> build tool in this case.

No, not really.  I think you're complaining that you already want to
know how to use the build system without having to learn it.  Language
syntax is only part of the problem.  You have to deal with build
capabilities no matter what the language.  You have to decide the
degree of control you will give the programmer over build
capabilities.  Basically, if you're going to give them any control at
all, they have to use something like CMake.  Else you just write a
build system for them and they use it off-the-shelf.

> For me the build tool is not a separate
> thing.  It is actually a good chunk of the application and the
> application shouldn't have to have multiple scripting languages.
> That's kind of absurd.  Granted, this is a very special case that
> doesn't apply to 99% of applications out there.

I'm failing to see why multimedia is special.  Just because you
despise having 2 languages doesn't make it absurd.

> Anyway, I've downloaded the Lua CMake branch.  I haven't looked
> thoroughly through the source yet, but from the wiki article, it seems
> like it could serve as a nice starting point for implementing this
> section of the application, especially if someone else is constantly
> improving the build engine :)

Be advised that Kitware is never going to officially release or
support the use of CMake as an API for a build engine.  They do not
want to be in that business, as it would tie their hands about the API
spec and add considerable support and documentation burdens over what
they currently do.  If you want to rip the lid off of CMake and just
reuse what's underneath, you're on your own.  If you nevertheless
think it's a good idea to go that route, and reuse Kitware's ongoing
core expertise, you should construct some kind of CMake "ripper"
script that does a good job of removing whatever you don't need from
the official sources.  Ideally, it would also have tests to detect
whether something has fundamentally changed about the CMake codebase
that invalidates your previous assumptions about core behavior.

If you grab the CMake sources once, start writing your own system, and
never bother with Kitware's code again, then you lose Kitware's
ongoing gruntwork, the stuff that tames the cross-platform build
problem.  The fact that Kitware is actually doing the work, and you
really don't want to, is the reason you put up with a different
scripting language for the build system.

It would make a lot more sense to write a Lua <--> CMake script
translator and use it judiciously in conjuction with official CMake.
Politically, you could probably build a community around that.   You
might even get Kitware to accept it as official, if it reached
sufficient maturity.  I would expect that to be a long way down the
road though.  You'd have a lot to prove to people.  If proving things
to people isn't your bag, then I think you will inevitably develop a
Lua-centric multimedia tool that has nowhere near the cross-platform
build quality of a CMake-based system.


Cheers,
Brandon Van Every