Re: [Boost-build] Summer of Code 2006

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-22 13:47:56

[Moving to the Boost.Build list; that's where this belongs]

Walter Landry <wlandry_at_[hidden]> writes:

> David Abrahams <dave_at_[hidden]> wrote:
>> Walter Landry <wlandry_at_[hidden]> writes:
>> 
>> > [1] For example, I can not figure out how to get it to use g++-4.1
>> >     instead of the default g++ (which is 4.0).  This is really
>> >     unacceptable.  It shouldn't take me more than 30 seconds to figure
>> >     that out.
>> 
>> Boost.Build v2:
>> 
>>         # ~/user-config.jam
>>         using gcc : : path/to/g++-4.1 ;
>> 
>> makes g++-4.1 your default gcc.  Of course you can also register your
>> versions separately:
>> 
>>         using gcc : 4.0 : g++ ;
>>         using gcc : 4.1 : path/to/g++-4.1 ;
>> 
>> couldn't be much easier.
>
> This does not do what I want.  I want to be able to type a short
> command (like "make" or "bjam"), and have it build with the compiler I
> specified when I configured.  

It absolutely does do that.

> So different directories would use different compilers.  I configure
> once (with all sorts of esoteric commands and locations), but build
> many times.

Oh, you want per-directory sticky selection of default toolset.
That's an interesting idea, and probably easy to add.

> It also does not help that this is not at all like the instructions
> given on the webpage.  The webpage says that I can run configure in
> libs/config and copy user.hpp to the right place.  

Wow, you're pretty confused I think.  "The webpage" you're looking at
has nothing to do with Boost.Build.  John created a configure script
to help with the deduction of #defines for the Boost.Config library.
That's all it does, and that's all it's supposed to do.  This whole
thing predates Boost.Build by some considerable time (years, I think).

Whatever it is that caused you to be confused about that should be
fixed in the documentation.  Maybe you can make some useful
suggestions; I think I'm too close to it.

On the other hand, you can get a working *nix configure/make/make
install script for all of boost at
http://www.boost-consulting.com/boost/configure.  It will go out at
the top level of the next release.

> That does not work.

What, specifically, do you mean when you say that?

> It is made even more difficult to debug because bjam prints out
> unhelpful lines like
>
>   gcc-C++-action bin/boost/libs/regex/build/libboost_regex.so/gcc/release/shared-linkable-true/threading-multi/cregex.o
>
> instead of the actual command that it is executing.  "bjam --help"
> gives no clue about how to get the actual command.

Works for me (using BBv2, v1 is about to be retired):

  %bjam --help
  Configuration help:

    Configuration file at /usr/home/dave/user-config.jam

   This file is used to configure your Boost.Build installation. Please read
   the user manual to find out where to put it.

  Available Help:

    These are the available options for obtaining documentation. Some options
    have additional instructions on how to get more detailed information.
    Multiple options are allowed and sometimes required. For example, the options
    that configure the help system still require a regular help request option
    for any output to be generated.

  * --help; This help message.
  * --help-usage; How to invoke 'bjam.'
  * --help-all; Brief information on available modules.
  * --help <module-name>; Get information about a module.
  * --help-options; Options for controlling the help display.
  * --help-output <type>; The type of output to genetare. 'console is formated
    text echoed to the console (the default);' 'text is formated text appended to
    the output file;' 'html is HTML output to the file.'
  * --help-output-file <file>; The file to output the documentation.

  ...found 1 target...
  %bjam --help-usage
  Boost.Jam Usage:

    bjam [ options... ] targets...

  * -a; Build all targets, even if they are current.
  * -fx; Read 'x' as the Jamfile for building instead of searching for the
    Boost.Build system.
  * -jx; Run up to 'x' commands concurrently.
  * -n; Do not execute build commands. Instead print out the commands as they
    would be executed if building.
  * -ox; Write the build commands to the file 'x'.
  * -q; Quit as soon as the build of a target fails. Specifying this prevents
    the attempt of building as many targets as possible regardless of failures.
  * -sx=y; Sets a Jam variable 'x' to the value 'y', overriding any value that
    variable would have from the environment.
  * -tx; Rebuild the target 'x', even if it is up-to-date.
  * -v; Display the version of bjam.
  * --x; Option 'x' is ignored but considered and option. The option is then
    available from the 'ARGV' variable.
  * -dn; Enables output of diagnostic messages. The debug level 'n' and all
    below it are enabled by this option.
  * -d+n; Enables output of diagnostic messages. Only the output for debug
    level 'n' is enabled.

  Debug Levels:

    Each debug level shows a different set of information. Usually with the
    higher levels producing more verbose information. The following levels are
    supported:

  * 0; Turn off all diagnostic output. Only errors are reported.
  * 1; Show the actions taken for building targets, as they are executed.
  * 2; Show quiet actions and display all action text, as they are executed.
  * 3; Show dependency analysis, and target/source timestamps/paths.
  * 4; Show arguments of shell invocations.
  * 5; Show rule invocations and variable expansions.
  * 6; Show directory/header file/archive scans, and attempts at binding to
    targets.
  * 7; Show variable settings.
  * 8; Show variable fetches, variable expansions, and evaluation of 'if'
    expressions.
  * 9; Show variable manipulation, scanner tokens, and memory usage.
  * 10; Show execution times for rules.
  * 11; Show parsing progress of Jamfiles.
  * 12; Show graph for target dependencies.
  * 13; Show changes in target status (fate).

That's -d+5.

It seems as though it's very difficult to satisfy anybody w.r.t. the
output of a Build/Install system.  Several people just wanted a
progress indicator that was otherwise silent, and for a while I was
convinced that would be best, but was about to change the default and
many experienced Boost.Build users got very upset about it.  Many
others didn't like the idea of showing the full text of the build
actions by default.  Apparently the current output is perfect for many
people.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com