[Boost-build] Refactoring build-system.jam

From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-01-06 01:41:42

   Hi.

   I refactored and committed build-system.jam 
(http://svn.boost.org/trac/boost/changeset/42508). Broke that one big 
function into separate rules and added loads of comments.

   That was the setup for changes I'd like to do there in order to be 
able to prepare some tests I have in mind. Here are the planned changes 
so comment if I should not go ahead with them (already done in my 
sandbox, together with the tests I needed):

   1. Add a new command-line option --test-config for specifying a test
configuration file instead of testing whether test-config.jam is located 
on some hard-coded path. This allows each test to decide whether it 
wants to use some central configuration file, none or its own custom 
one. Requires slight tweaks in build-system.jam and BoostBuild.py.

   2. Make test configuration not disable toolset autoconfiguration. I 
do not know why it did that as it does not cause problems with any tests 
I ran but it does prevent me from preparing a test demonstrating a bug 
with using an autoconfigured default toolset. If we do need this 
disabling it would be trivial to add a clean explicit option for this.
Changes boil down to removing one assignment in build-system.jam.

   3. Add a way for configuration scripts to set the toolset used by 
default (instead of msvc/gcc). If not set - current behaviour is used. 
Again, needed for the test mentioned above. Slight addition to 
toolset.jam and boost-build.jam.

   4. Split up --ignore-config option into separate options as this one 
has too many duties, some of which are not even documented, its name 
does not reflect its duties and at least one of its duties seems like a bug.
   * Prevents loading site configuration. --> I'd add a 
--ignore-site-config option for this.
   * Prevents loading user configuration. --> We can do this after this 
last cleanup I did by specifying --user-config= or --user-config="" on 
the command line.
   * Disables Boost Build's toolset auto-configuration. --> As above, if 
this is really needed - it would be trivial to add a 
--disable-toolset-autoconf option or something similar.
   * As a consequence of disabling Boost Build's toolset 
auto-configuration the --toolset option does not work. You can still 
specify a toolset using the toolset=XXX format or simply using it as an 
implicit feature value XXX. --> This one I believe is a pure bug...

   All of this is easily implemented... anyone have any ideas on why it 
should not be implemented?

   Best regards,
     Jurko Gospodnetiæ