On May 9, 2007, at 2:36 PM, Rene Rivera wrote:
Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
The problem with that approach is that it creates extra work that "users" must do to build. And any extra work the build system doesn't have control over raises the likelihood something will go wrong. For example, someone may forget that they need different dirs and accidentally reuse an existing one. Which could create all kinds of collisions and hard to diagnose errors.
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
In the same sense that Boost.Build is written on top of Boost.Jam, it might make sense to treat cmake as a backend to a slim build description and control front end.
I strongly disagree with this approach, because it negates any of the positive effects of using an off-the-shelf build system. We expend a lot of effort maintaining Boost.Build, much of which could be avoided if we bought into an existing system rather than rolling our own. To switch to another "back-end" and still roll our own... that would just be more wasted effort. - Doug