Ticket #9304: bjam-b2-docs-cleanup.patch

File bjam-b2-docs-cleanup.patch, 8.1 KB (added by Mateusz Loskot, 9 years ago)

Patch with bjam vs b2 clean up

  • tools/build/v2/doc/src/architecture.xml

     
    8383
    8484        <listitem><para>
    8585          The targets are returned to the top level code. They are converted
    86         into bjam targets (via <code>virtual-target.actualize</code>) and passed
    87         to bjam for building.
     86          into Boost Build targets (via <code>virtual-target.actualize</code>)
     87          and passed to Boost Build for building.
    8888        </para></listitem>
    8989      </orderedlist>
    9090    </para>
    … …  
    166166        Virtual targets correspond to atomic updatable entities. Each virtual
    167167      target can be assigned an updating action -- instance of the
    168168      <code>action</code> class. The action class, in turn, contains a list of
    169       source targets, properties, and a name of an bjam action which should be
    170       executed.
     169      source targets, properties, and a name of an Boost Build action which
     170      should be executed.
    171171      </para>
    172172
    173173      <para>
    … …  
    183183      that the real file names are computed, and the commands that should be run
    184184      are generated. This is done by the <code>virtual-target.actualize</code>
    185185      and <code>action.actualize</code> methods. The first is conceptually
    186       simple, while the second needs additional explanation. Commands in bjam
     186      simple, while the second needs additional explanation. Commands in Boost Build
    187187      are generated in a two-stage process. First, a rule with an appropriate
    188188      name (for example "gcc.compile") is called and is given a list of target
    189189      names. The rule sets some variables, like "OPTIONS". After that, the
    … …  
    308308      <para>
    309309        As stated above, it is possible to compile a C++ file multiple times,
    310310      using different include paths. Therefore, include dependencies for those
    311       compilations can be different. The problem is that bjam does not allow
     311      compilations can be different. The problem is that Boost Build does not allow
    312312      multiple scans of the same target.
    313313      </para>
    314314
    315315      <para>
    316316        The solution in Boost.Build is straightforward. When a virtual target is
    317       converted to a bjam target (via the
     317      converted to a Boost Build target (via the
    318318      <literal>virtual-target.actualize</literal> method), we specify the
    319       scanner object to be used. The actualize method will create different bjam
     319      scanner object to be used. The actualize method will create different Boost Build
    320320      targets for different scanners.
    321321      </para>
    322322
    … …  
    355355        <listitem><simpara>
    356356          If when compiling "a.cpp" there is an include of "a.h", the "dir"
    357357        directory is on the include path, and a target called "a.h" will be
    358         generated in "dir", then bjam should discover the include, and create
     358        generated in "dir", then Boost Build should discover the include, and create
    359359        "a.h" before compiling "a.cpp".
    360360        </simpara></listitem>
    361361

  • tools/build/v2/doc/src/extending.xml

     
    613613        and the target type. When invoked, the generator will create a target
    614614        of type <literal>CPP</literal> with a source target of
    615615        type <literal>VERBATIM</literal> as the only source. But what command
    616         will be used to actually generate the file? In bjam, actions are
     616        will be used to actually generate the file? In Boost Build, actions are
    617617        specified using named "actions" blocks and the name of the action
    618618        block should be specified when creating targets. By convention,
    619619        generators use the same name of the action block as their own id. So,
    … …  
    970970
    971971
    972972          <para> Note the <code>bind DEF_FILE</code> part. It tells
    973           bjam to translate the internal target name in
     973          Boost Build to translate the internal target name in
    974974          <varname>DEF_FILE</varname> to a corresponding filename in
    975975          the <code>link</code> action.  Without it the expansion of
    976976          <code>$(DEF_FILE)</code> would be a strange symbol that is
    … …  
    992992</programlisting>
    993993<!-- You *must* explain the part in [...] above. It's completely opaque to the casual reader -->
    994994
    995             This is needed to accomodate some bug in bjam, which hopefully
     995            This is needed to accomodate some bug in Boost Build, which hopefully
    996996            will be fixed one day.
    997997            <!-- This is *NOT* a bug!!  Anyway, BBv2 shouild handle this automatically. Why doesn't it? -->
    998998</para></listitem>

  • tools/build/v2/doc/src/install.xml

     
    103103              </para>
    104104
    105105              <para>Placing Boost.Build into <filename>/usr/share/boost-build</filename>
    106               will make sure that <command>bjam</command> will find Boost.Build
     106              will make sure that <command>b2</command> will find Boost.Build
    107107              without any additional setup.</para>
    108108            </listitem>
    109109
    … …  
    120120        </para>
    121121
    122122        <para>If those guidelines are met, users will be able to invoke
    123         <command>bjam</command> without any explicit configuration.
     123        <command>b2/command> without any explicit configuration.
    124124        </para>
    125125
    126126   

  • tools/build/v2/doc/src/overview.xml

     
    580580
    581581    <section id="bbv2.overview.invocation">
    582582      <title>Invocation</title>
     583     
     584      <note>
     585        <para>
     586            As of Boost 1.47.0, the official name of Boost.Build executable is <command>b2</command>. The bootstrap scripts create a copy with the old name <command>bjam</command> to prevent third-party build scripts from failing. Authors are encouraged to update their scripts to refer to the new name.
     587        </para>
     588      </note>
    583589
    584590      <para>To invoke Boost.Build, type <command>b2</command> on the command line. Three kinds
    585591      of command-line tokens are accepted, in any order:</para>

  • tools/build/v2/doc/src/reference.xml

     
    1717    <section id="bbv2.reference.init">
    1818      <title>Initialization</title>
    1919
    20       <para>bjam's first job upon startup is to load the Jam code that
     20      <para>First job of the Boost Build's command <command>b2</command>
     21        upon startup is to load the Jam code that
    2122        implements the build system. To do this, it searches for a file
    2223        called <filename>boost-build.jam</filename>, first in the invocation directory, then
    2324        in its parent and so forth up to the filesystem root, and finally

  • tools/build/v2/doc/src/tasks.xml

     
    447447      <varname>args</varname> and <varname>input-files</varname> as command-line
    448448      arguments. The <varname>args</varname> parameter is passed verbatim and
    449449      the values of the <varname>input-files</varname> parameter are treated as
    450       paths relative to containing Jamfile, and are adjusted if <command>bjam
    451       </command> is invoked from a different directory. The
     450      paths relative to containing Jamfile, and are adjusted if <command>b2</command>
     451      is invoked from a different directory. The
    452452      <code>run-fail</code> rule is identical to the <code>run</code> rule,
    453453      except that it expects that the run fails.
    454454    </para>