Re: Premake vs. CMake

["Wesley Smith" <wesley.hoke@...>]

On Feb 2, 2008 10:54 PM, Brandon Van Every <bvanevery@gmail.com> wrote:
> 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
>