From 84fbf5d2ca3645f52998cfbfa4889db4b08285b1 Mon Sep 17 00:00:00 2001 From: Vladimir Prus Date: Fri, 26 Sep 2003 11:15:23 +0000 Subject: [PATCH] Document new link-compatibility rules. [SVN r20192] --- boost_build_v2.html | 75 +++++++++++++++++++++++++-------------------- 1 file changed, 42 insertions(+), 33 deletions(-) diff --git a/boost_build_v2.html b/boost_build_v2.html index 447140833..0bae4791f 100644 --- a/boost_build_v2.html +++ b/boost_build_v2.html @@ -22,12 +22,12 @@ div.alert { color: red } table { align: center; border: thin; } - + + - build request, build request expansion and directly requested targets + - conditional properties + -->

bjam there. A simple application will be built. You can also play with other projects in examples-v2. + it somewhere. + +

It is slighly better way is to copy new/user-config.jam + into one of the locations where it can be found (given in this table). This prevent you from + accidentally overwriting your config when updating.

--> @@ -1029,17 +1029,17 @@ boost-build /path/to/boost.build ;
  • It allows to have main target names with slashes. + That makes good rationale for why main target must contain names. + -->
    • @@ -1352,25 +1352,30 @@ rule feature ( name : allowed-values * : attributes * ) build requirements. We need to determine whether a buildable version of that target can actually be used.

    -

    The build request can originate in many ways: It may come directly +

    The build request can originate in many ways: it may come directly from the user's command-line, from a dependency of a main target upon a library, or from a dependency of a target upon an executable used to build that target, for example. For each way, there are different rules - whether we can use a given subvariant or not. However we currently only - assume linking and therefore use a simple approach described in the - following paragraph.

    - -

    In general, there are many possible situations: a libary which is - dependency of a main target and should be linked into it, target which is - directly requested on the command line, or build executable which is used - in the build process itself. At this moment we use a simple approach.

    + whether we can use a given subvariant or not. The current rules are + described below.

    Two property sets are called link-compatible when targets with those property sets can be used interchangably. In turn, two property sets are link compatible when there's no link-incompatible - feature which has different values in those property sets. Whenever - requested and actual properties are link-compatible, it's OK. Otherwise, - it's an error.

    + feature which has different values in those property sets.

    + +

    When building of a main target is requested from a command line or + some project, link-compatibility is not considered. When building is + requested by other main target, via sources or dependency properties, the + requested and actual property sets must be link-compatible, otherwise a + warning is produced.

    + +

    Rationale:Link-compatibility is not considered when main target + is requested by a project, because it causes problems in practice. For + example, some parts of a project might be single-threaded, while others + — multi-threaded. They are not link-compatible, but they are not + linked, either. So, there's no need to issue error or warning. The errors + used to be generated, and only caused problems.

    Definition of property refinement

    @@ -1659,7 +1664,7 @@ borland/runtime-link=static,dynamic
  • - For each selected alternative + For the selected alternative
    1. Each target reference in the source list are recursively @@ -1675,6 +1680,10 @@ borland/runtime-link=static,dynamic generators.
    • + +
  • If, when building sources, the properties on recursively created + targets are not link-compatibile with build properties, a warning is + issued.

    • Generated headers