boost/build
2
0
Fork 0
mirror of https://github.com/boostorg/build.git synced 2026-02-15 00:52:16 +00:00
Code Issues Projects Releases Wiki Activity

Typo corrections. Minor stylistic changes.

Browse Source 
[SVN r42480]
This commit is contained in:
Jurko Gospodnetić
2008-01-05 16:55:36 +00:00
parent 15da5cdfba
commit 9fd5e06057
3 changed files with 31 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
v2/build/project.jam
View File

@@ -289,8 +289,7 @@ local rule load-jamfile (
{
jamfile-to-load = [ find-jamfile $(dir) ] ;
}
# The module of the jamfile.
#
local jamfile-module = [ module-name [ path.parent $(jamfile-to-load) ] ] ;
@@ -324,7 +323,7 @@ local rule load-jamfile (
{
errors.error "The value of the .current-project variable"
: "has magically changed after loading a Jamfile."
: "This means some of the targets might be defined a the wrong project."
: "This means some of the targets might be defined in the wrong project."
: "after loading " $(jamfile-module)
: "expected value " $(saved-project)
: "actual value " $(.current-project)
@@ -334,9 +333,9 @@ local rule load-jamfile (
if $(.global-build-dir)
{
local id = [ attribute $(jamfile-module) id ] ;
local project-root = [ attribute $(jamfile-module) project-root ] ;
local project-root = [ attribute $(jamfile-module) project-root ] ;
local location = [ attribute $(jamfile-module) location ] ;
if $(location) && $(project-root) = $(dir)
{
# This is Jamroot
@@ -349,10 +348,6 @@ local rule load-jamfile (
}
}
}
}
rule mark-as-user ( module-name )
@@ -883,10 +878,10 @@ module project-rules
if $(global-build-dir)
{
local location = [ $(attributes).get location ] ;
# Project with empty location is 'standalone' project, like
# user-config, or qt. It has no build dir.
# Project with an empty location is a 'standalone' project such as
# user-config or qt. It has no build dir.
# If we try to set build dir for user-config, we'll then
# try to inherit it, with either weird, or wrong consequences.
# try to inherit it, with either weird or wrong consequences.
if $(location) && $(location) = [ $(attributes).get project-root ]
{
# This is Jamroot.

3
v2/kernel/bootstrap.jam
View File

@@ -118,7 +118,7 @@ import modules ;
import option ;
local dont-build = [ option.process ] ;
# Should we skip building, i.e. loding the build system, according
# Should we skip building, i.e. loading the build system, according
# to the options processed?
#
if ! $(dont-build)
@@ -131,4 +131,3 @@ if ! $(dont-build)
# Use last element in case of multiple command-line options
import $(build-system[-1]) ;
}

49
v2/notes/build_dir_option.txt
View File

@@ -1,6 +1,6 @@
Copyright 2005 Vladimir Prus
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt)
Copyright 2005 Vladimir Prus
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt)
Summary
@@ -41,15 +41,15 @@ then with the same value of --build-dir we'd act as if Jamroot contained:
project foo : build-dir /tmp/build/foo/bin.v2 ;
We can't drop "bin.v2" because it's quite possible that the name of build
dir have specific meaning. For example, it can be used to
separate Boost.Build V2 and V1 build results.
We can't drop "bin.v2" because it's quite possible that the name of build dir
have specific meaning. For example, it can be used to separate Boost.Build V1
and V2 build results.
The --build-dir option has no effect if Jamroot does not define any project
id. Dowing otherwise can lead to nasty problems if we're building two distinct
The --build-dir option has no effect if Jamroot does not define any project id.
Doing otherwise can lead to nasty problems if we're building two distinct
projects (that is with two different Jamroot). They'll get the same build
directory. Most likely, user will see
the "duplicate target" error, which is generally confusing.
directory. Most likely, user will see the "duplicate target" error, which is
generally confusing.
It is expected that any non-trivial project will have top-level "project"
invocation with non empty id, so the above limitation is not so drastic.
@@ -57,24 +57,21 @@ We'll emit a warning if Jamroot does not define project id, and --build-dir
is specified.
Here's the exact behavior of the --build-dir option. If we're loading a
Jamfile (either root or non-root), that declare some project id and some
Jamfile (either root or non-root), that declare some project id and some
build-dir attribute, the following table gives the value of build-dir
that will actually be used.
Root? Id Build-dir attribute Resulting build dir
yes none * --build-dir is ignored, with warning
yes 'foo' none /tmp/build/foo
yes 'foo' 'bin.v2' /tmp/build/foo/bin.v2
yes 'foo' '/tmp/bar' Error [1]
no * none --build-dir has no effect, inherited build dir is used
no * non-empty Error [2]
-------------------------------------------------------------------------------
Root? Id Build-dir attribute Resulting build dir
-------------------------------------------------------------------------------
yes none * --build-dir is ignored, with warning
yes 'foo' none /tmp/build/foo
yes 'foo' 'bin.v2' /tmp/build/foo/bin.v2
yes 'foo' '/tmp/bar' Error [1]
no * none --build-dir has no effect, inherited
build dir is used
no * non-empty Error [2]
-------------------------------------------------------------------------------
[1] -- not clear what to do
[2] -- can be made to work, but non-empty build-dir
[2] -- can be made to work, but non-empty build-dir
attribute in non-root Jamfile does not make much sense even without --build-dir