mirror of
https://github.com/boostorg/build.git
synced 2026-02-13 12:22:17 +00:00
Fix various block highlight languages.
This commit is contained in:
@@ -10,7 +10,7 @@
|
||||
Boost.Build comes with a debugger for Jamfiles. To run the debugger,
|
||||
start Boost.Build with `b2 -dconsole`.
|
||||
|
||||
----
|
||||
....
|
||||
$ b2 -dconsole
|
||||
(b2db) break gcc.init
|
||||
Breakpoint 1 set at gcc.init
|
||||
@@ -19,7 +19,7 @@ Starting program: /usr/bin/b2
|
||||
Breakpoint 1, gcc.init ( ) at /usr/share/boost-build/tools/gcc.jam:74
|
||||
74 local tool-command = ;
|
||||
(b2db) quit
|
||||
----
|
||||
....
|
||||
|
||||
[[bbv2.util.debugger.running]]
|
||||
=== Running the Program
|
||||
@@ -46,32 +46,32 @@ the module name) or or a file name and line number of the form
|
||||
`file:line`. When a breakpoint is created it is given a unique id which
|
||||
is used to identify it for other commands.
|
||||
|
||||
----
|
||||
....
|
||||
(b2db) break Jamfile:10
|
||||
Breakpoint 1 set at Jamfile:10
|
||||
(b2db) break msvc.init
|
||||
Breakpoint 2 set at msvc.init
|
||||
----
|
||||
....
|
||||
|
||||
A breakpoint can be temporarily disabled using the `disable` command.
|
||||
While a breakpoint is disabled, the child will not stop when it is hit.
|
||||
A disabled breakpoint can be activated again with `enable`.
|
||||
|
||||
----
|
||||
....
|
||||
(b2db) disable 1
|
||||
(b2db) enable 1
|
||||
----
|
||||
....
|
||||
|
||||
Breakpoints can be removed permanently with `delete` or `clear`. The
|
||||
difference between them is that `delete` takes the breakpoint id while
|
||||
`clear` takes the location of the breakpoint as originally specified to
|
||||
break.
|
||||
|
||||
----
|
||||
....
|
||||
(b2db) clear Jamfile:10
|
||||
Deleted breakpoint 1
|
||||
(b2db) delete 2
|
||||
----
|
||||
....
|
||||
|
||||
[[bbv2.util.debugger.stack]]
|
||||
=== Examining the Stack
|
||||
@@ -81,12 +81,12 @@ stack.
|
||||
|
||||
The `print` command can be used to show the value of an expression.
|
||||
|
||||
----
|
||||
....
|
||||
(b2db) print [ modules.peek : ARGV ]
|
||||
/usr/bin/b2 toolset=msvc install
|
||||
(b2db) print $(__file__)
|
||||
Jamfile.jam
|
||||
----
|
||||
....
|
||||
|
||||
[[bbv2.util.debugger.misc]]
|
||||
=== Miscellaneous Commands
|
||||
|
||||
@@ -46,6 +46,7 @@ commands that are used to create them from other target. The below
|
||||
example creates `a.o` from `a.c` using a hardcoded compiler invocation
|
||||
command.
|
||||
|
||||
[source,make]
|
||||
----
|
||||
a.o: a.c
|
||||
g++ -o a.o -g a.c
|
||||
@@ -59,6 +60,7 @@ To improve portability, most modern build system provide a set of
|
||||
higher-level functions that can be used in build description files.
|
||||
Consider this example:
|
||||
|
||||
[source,cmake]
|
||||
----
|
||||
add_program ("a", "a.c")
|
||||
----
|
||||
|
||||
@@ -814,7 +814,7 @@ using python
|
||||
: # conditions
|
||||
;
|
||||
|
||||
using python
|
||||
using python
|
||||
: 3.5 # version
|
||||
: # Interpreter/path to dir
|
||||
: /usr/include/python3.5 # includes
|
||||
@@ -828,7 +828,7 @@ using python
|
||||
: C:\\Python27-32\\python.exe # Interperter/path to dir
|
||||
: C:\\Python27-32\\include # includes
|
||||
: C:\\Python27-32\\libs # libs
|
||||
: <address-model>32 <address-model> # conditions - both 32 and unspecified
|
||||
: <address-model>32 <address-model> # conditions - both 32 and unspecified
|
||||
;
|
||||
|
||||
using python
|
||||
@@ -1519,9 +1519,9 @@ passing a command line option to it. You would not want to pass that
|
||||
option to other compilers. Conditional properties allow you to do just
|
||||
that. Their syntax is:
|
||||
|
||||
----
|
||||
....
|
||||
property ( "," property ) * ":" property
|
||||
----
|
||||
....
|
||||
|
||||
For example, the problem above would be solved by:
|
||||
|
||||
@@ -1542,14 +1542,14 @@ exe hello : hello.cpp : <os>NT,<toolset>gcc:<link>static ;
|
||||
|
||||
_Target identifier_ is used to denote a target. The syntax is:
|
||||
|
||||
----
|
||||
....
|
||||
target-id -> (target-name | file-name | project-id | directory-name)
|
||||
| (project-id | directory-name) "//" target-name
|
||||
project-id -> path
|
||||
target-name -> path
|
||||
file-name -> path
|
||||
directory-name -> path
|
||||
----
|
||||
....
|
||||
|
||||
This grammar allows some elements to be recognized as either
|
||||
|
||||
@@ -1583,10 +1583,10 @@ _Target reference_ is used to specify a source target, and may
|
||||
additionally specify desired properties for that target. It has this
|
||||
syntax:
|
||||
|
||||
----
|
||||
....
|
||||
target-reference -> target-id [ "/" requested-properties ]
|
||||
requested-properties -> property-path
|
||||
----
|
||||
....
|
||||
|
||||
For example,
|
||||
|
||||
|
||||
@@ -181,7 +181,7 @@ project of a subproject is defined by the nearest Jamfile
|
||||
file in an ancestor directory. For example, in the following directory
|
||||
layout:
|
||||
|
||||
----
|
||||
....
|
||||
top/
|
||||
|
|
||||
+-- Jamfile
|
||||
@@ -197,7 +197,7 @@ top/
|
||||
. |
|
||||
. +-- Jamfile
|
||||
. `-- bar.cpp
|
||||
----
|
||||
....
|
||||
|
||||
the project root is `top/`. The projects in `top/app/` and
|
||||
`top/util/foo/` are immediate children of the root project.
|
||||
|
||||
Reference in New Issue
Block a user