[boost] Improved build process

Subject: [boost] Improved build process
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-04-11 11:23:31

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