on Mon Feb 18 2008, Hendrik Belitz
Rene Rivera wrote:
Cmake is *technically* not a build system. It is a meta-build system.
Okay, thanks for clarifying that. Although I think that Rüdigers is looking for something you call meta-build system in fact.
Rüdiger,
There is nothing wrong with Boost.Build. It works as it should, and it is a very sophisticated alternative to gmake and nmake, offering a much clearer syntax and platform independence. But it is still a low-level build tool
I'm keenly aware of several Boost.Build shortcomings, but that's just not accurate.
like it's competitors.
Hard to say without knowing what you consider to be its competitors.
Expect to do a lot of of things by hand which can be solved easily in a automated way by using something Rene called a "meta-build" system.
The distinction between "build" and "meta-build" is not low- vs. high- level. The only difference is that a meta-build system uses an intermediate build language and a (non-meta) build system does not. You can create a "non-meta" build system that is arbitrarily high-level, automating as much as you might like. In fact, Boost.Build is a high-level build system built atop a low-level substrate called "bjam."
This is especially an issue for open-source projects which often rely on other toolkits and libraries already installed on the system. There are definitely some pretty neat ways to define automated detection rules for these external dependencies in Boost.Build (in fact, you can do these things which any build system), but this might involve a tedious amount of work; this is something you can just circumvent by using a higher-level tool like automake or (for people who dislike automake's approach) CMake.
It sounds like you're confused. Either the high-level tool does the work for you or it does not. In many cases Boost.Build is able to do this sort of detection, just as CMake or automake would, and I'm willing to be that it has some detection capabilities that neither of the others has. The advantage of a meta-build approach used in CMake and automake is that they can spend arbitrary amounts of time on detection (once) without slowing things down every time through the compile/edit/debug cycle.
Another good point is the generation of platform-dependent makefiles or project files which integrate seamlessly in your current development environment.
Not true for CMake. You can't decouple the generated makefiles from CMake and expect to continue development for very long, because CMake writes *extremely* low-level makefiles that don't even handle such things as header dependency management.
Using Eclipse, who might want to have eclipse project files for you source tree. For Visual Studio or KDevelop, you also want to have building and dependency information.
OK, for IDE project files, that's true... provided that the IDE can represent the same kind of high-level information that is represented in your high-level build system.
Using low-level build tools, you have to generate these things by hand. Using high-level tools, the output will match your desired development environment.
That is not a low-level vs. high-level difference, but simply an important feature difference. Boost.Build doesn't have the ability to generate IDE project files yet, so that is an advantage of CMake (but not of automake).
To summarize this, low-level tools enable you to use a "define once, build everywhere" approach, while high-level tools support the more generalized of approach of "define once, develop everywhere". While this doesn't matter for smaller projects, the latter approach is preferable for all projects involving several developers, maybe even on different developing platforms.
All true, but not a distinction that applies to Boost.Build, which was designed with "define once, develop everywhere" in mind, and achieves that goal admirably. -- Dave Abrahams Boost Consulting http://boost-consulting.com