Hello, I have completed a set of changes meant to make building C++ Boost somewhat more streamlined, and avoid common pitfalls reported on IRC and mailing lists. In short, C++ Boost can now be build, on Windows, with: bootstrap.bat bjam and on Linux, with ./bootstrap.sh ./bjam I'd imagine that 95% of users won't need anything else, and two commands is a fairly straigh-forward approach. More specifically, the changes I've made are: 1. Some time ago we discussed the configure/make solution: http://article.gmane.org/gmane.comp.lib.boost.devel/181839/ There are two problems with it: - The naming suggests it's automake/autoconf solution, which is not, and users keep on trying automake idioms to find they don't work. - If you just run "bjam" then whatever settings configure made are not considered -- which is very annoying when user has to tweak things beyond what configure offers. Per that thread, I have did two changes: - Renamed configure to bootstrap.sh, avoiding autoconf connotations - Made bootstrap.sh, instead of generating Makefile, generate project-config.jam -- which is automatically read by Boost.Build. 2. Many users forget to specify 'stage' explicitly, and get a pile of libraries in random places. Now, 'stage' is default, and a message saying where libraries go is printed. See: http://article.gmane.org/gmane.comp.lib.boost.devel/188450 3. On Windows, users had to get or build Boost.Jam, and then copy it in %PATH% and then invoke it. Now, bootstrap.bat is a tiny wrapper that builds Boost.Jam and puts it in the root of C++ Boost source tree. 4. On Windows, release libraries were built by default, and debug were not build at all, which does not match default IDE & autolink behaviour. (I think that on Linux, building release by default is fine, since generally debug and release versions are link-compatible). We now build these two variants by default: <variant>debug <threading>multi <link>static <runtime-link>shared <variant>release <threading>multi <link>static <runtime-link>shared These changes are presently on trunk. Most of them are essentially the matter of proper defaults, and proper messages and proper wrappers, not deep hacking, so they are unlikely to disturbing for release. On the other hand, I would very much appreciate comments on "look&feel". So, if you have some time, give it a try and report your experience. I'll take a look at regression results to see if some unexpected breakage appears, and do other round of manual testing on Monday, and then merge this to release branch. Dave, I understand this requires changes to getting started -- for Unix, they are textual replacements only and I have a local patch for that. For Windows, new text is needed that I'll work on as well and should have a patch for your review by Monday. - Volodya