Rene Rivera wrote:
Stefan Seefeld wrote:
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.
Well, well, there are certainly mechanisms that could be put into place to help diagnose such errors (such as putting some timestamp / variant-stamp files into the build dir). Also, while it is certainly true that this requires more 'manual' intervention, as far as the build system itself is concerned, there is nothing preventing boost from adding a (tiny and un-intrusive) layer on top that makes sure those steps are enforced. However, this is a *much* better design as it reduces the scope of the build system, makes things more transparent, and enhances modularity (through a clearer separation of concern).
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.
Right. I'm sure we can beat buildbot into shape for that, too. ;-) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...