[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Premake vs. CMake
- From: "Thiago Bastos" <tabastos@...>
- Date: Sun, 3 Feb 2008 11:48:23 -0300
2008/2/3, Brandon Van Every <firstname.lastname@example.org>:
Nobody has yet made a successful case that for a large project,
"fullblown" scripting languages can do things that CMake script can't.
Perhaps that case could be made, and I keep looking around for an
exemplar of it, but it hasn't been made. I think Kitware would be
receptive to the argument *if* it could be made, but nobody's been
able to make it. People keep talking about things that Kitware is
capable of addressing by improving CMake in pretty much the form it's
Please enlighten me if the following 'case' can be easily implemented with CMake.
I'm not sure, but couldn't find the necessary means by browsing the documentation.
Consider a large component-based application. Its build script has several 'build options' that enable/disable the integration of some set of components into the application.
These (more than 50) components are not distributed with the application's source code, they are rather automatically downloaded by the build script based on the build options (since there are so many optional components, only those needed components should be downloaded).
Now, for every downloaded component, the build script should run some custom tool on the IDL files that come with the component bundles, then build the application, then create a installer for the application including the components that were downloaded.
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.