# The following modules must be installed for Python. You can obtain the **repo** file from the source code of the build environment mentioned in **Constraints**.
# The following modules must be installed for Python. You can obtain the repo file from the source code of the build environment you use.
>Due to the limitation of the image size, the full build for the debug version may fail to be burnt. You are advised to build the binary file for each module separately. Run the following command to build a module separately:
-v, --verbose show all command lines while building
-shs, --sign_haps_by_server
sign haps by server
--patch apply product patch before compiling
--compact-mode compatible with standard build system set to false if we use build.sh as build entrance
--gn-args GN_ARGS specifies gn build arguments, eg: --gn-args="foo="bar" enable=true blah=7"
--keep-ninja-going keeps ninja going until 1000000 jobs fail
--build-only-gn only do gn parse, donot run ninja
--log-level LOG_LEVEL
specifies the log level during compilationyou can select three levels: debug, info and error
--fast-rebuild it will skip prepare, preloader, gn_gen steps so we can enable it only when there is no change
for gn related script
--device-type DEVICE_TYPE
specifies device type
--build-variant BUILD_VARIANT
specifies device operating mode
```
- If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the build. The **-f** option deletes all products to be built. It is equivalent to running **hb clean** and **hb build**.
- You can run **hb build***{component_name}* to build product components separately based on the development board and kernel set for the product, for example, **hb build kv_store**.
- You can run **hb build -p ipcamera@hisilicon** to skip the setting step and build the product directly.
- You can run **hb build** in **device/board/device_company** to select the kernel and build an image that contains the kernel and drivers only based on the current development board and the selected kernel.
**hb clean**
Deletes all the files except **args.gn** and **build.log** in the **out** directory (default). To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/board/product**.
2. Using the hb tool
**hb** is an OpenHarmony command line tool for executing build commands. Common hb commands are described as follows:
**hb set**
Sets the product to build.
```shell
hb set -h
usage: hb set [-h] [-root [ROOT_PATH]] [-p]
optional arguments:
-h, --help show this help message and exit
-root [ROOT_PATH], --root_path [ROOT_PATH]
Set OHOS root path
-p, --product Set OHOS board and kernel
```
- If you run **hb set** with no argument, the default setting process starts.
- You can run **hb set -root** *dir* to set the root directory of the source code.
- You can run **hb set -p** to set the product to build.
-v, --verbose show all command lines while building
-shs, --sign_haps_by_server
sign haps by server
--patch apply product patch before compiling
--compact-mode compatible with standard build system set to false if we use build.sh as build entrance
--gn-args GN_ARGS specifies gn build arguments, eg: --gn-args="foo="bar" enable=true blah=7"
--keep-ninja-going keeps ninja going until 1000000 jobs fail
--build-only-gn only do gn parse, do not run ninja
--log-level LOG_LEVEL
specifies the log level during compilationyou can select three levels: debug, info and error
--fast-rebuild it will skip prepare, preloader, gn_gen steps so we can enable it only when there is no change
for gn related script
--device-type DEVICE_TYPE
specifies device type
--build-variant BUILD_VARIANT
specifies device operating mode
```
- If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the build. The **-f** option deletes all products to be built. It is equivalent to running **hb clean** and **hb build**.
- You can run **hb build** *{component_name}* to build product components separately based on the development board and kernel set for the product, for example, **hb build kv_store**.
- You can run **hb build -p ipcamera@hisilicon** to skip the setting step and build the product directly.
- You can run **hb build** in **device/board/device_company** to select the kernel and build an image that contains the kernel and drivers only based on the current development board and the selected kernel.
**hb clean**
Deletes all the files except **args.gn** and **build.log** in the **out** directory (default). To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/board/product**.
```shell
hb clean
usage: hb clean [-h] [out_path]
positional arguments:
out_path clean a specified path.
optional arguments:
-h, --help show this help message and exit
```
```shell
hb clean
usage: hb clean [-h][out_path]
positional arguments:
out_path clean a specified path.
optional arguments:
-h, --help show this help message and exit
```
### Building Procedures
...
...
@@ -366,6 +380,7 @@ You can add and build a product, component, chipset solution, and module. For de
## Reference
-[deps and external_deps](subsys-build-reference.md#deps-and-external_deps)
@@ -8,9 +8,9 @@ When adding a module, you must declare its dependencies in **BUILD.gn**. **deps*
The dependency between modules can be classified into **desp** (left in the figure above) and **external_deps** (right in the figure above).
The dependency between modules can be classified into **deps** (left in the figure above) and **external_deps** (right in the figure above).
-**desp**: The dependent module to be added belongs to the same part with the current module. For example, module 2 depends on module 1, and both modules 1 and 2 belong to the samp component.
-**deps**: The dependent module to be added belongs to the same part with the current module. For example, module 2 depends on module 1, and both modules 1 and 2 belong to the same component.
-**external_deps**: The dependent module to be added belongs to another component. For example, module 2 depends on module 1, and modules 1 and 2 belong to different components.
...
...
@@ -32,8 +32,8 @@ The dependency between modules can be classified into **desp** (left in the figu
deps =[
"GN target of module 1",
...
]# Intra-component dependency
part_name ="part1"# (Mandatory) Name of the component to which the module belongs.
]# Intra-component dependency
part_name ="part1"# (Mandatory) Name of the component to which the module belongs.
}
```
...
...
@@ -56,11 +56,60 @@ The dependency between modules can be classified into **desp** (left in the figu
"part1:module1",
...
]# Inter-component dependency. The dependent module must be declared in inner_kits by the dependent component.
part_name ="part2"# (Mandatory) Name of the component to which the module belongs.
part_name ="part2"# (Mandatory) Name of the component to which the module belongs.
}
```
**NOTE**<br>The dependency between components must be written in the format of **Component_name:Module_name** in **external_deps**. The dependent module must be declared in **inner_kits**.
**NOTE**<br>The dependency between components must be written in the format of **Component name:Module name** in **external_deps**. The dependent module must be declared in **inner_kits**.
## Using Sanitizer
When adding a module, you can enable Sanitizer functions, such as the integer overflow check and control-flow integrity (CFI), provided by the compiler as required. You can also enable the debug or release mode and configure a blocklist. Each configuration item is optional. It is **false** by default. You can also leave it empty.
Sanitizer configuration example:
``` shell
ohos_shared_library("example"){
sanitize ={
cfi =true
integer_overflow =true
debug =true# Optional. The debug mode is disabled by default.
blocklist ="./blocklist.txt"# Optional. Enter the path of the blocklist.
}
...
}
```
**Sanitizer Functions**
Currently, Sanitizers provides the following functions:
- Integer overflow check: provides check of unsigned integers (unsigned_integer_overflow), check of signed integers (signed_integer_overflow), or both (integer_overflow).
- CFI: prevents malware attacks from redirecting the control flow of a program.
**Release and Debug Modes**
**Debug** specifies whether the debug mode or the release mode is used. The default value **false** indicates that the release mode is used. The value **true** explicitly declares the debug mode. Do not use the debug mode in the build of the release version.
- Debug mode: If debug mode is enabled, abundant error-related information is provided to help locate faults. When an error occurs, the application will be resumed instead of being interrupted to further identify subsequent errors. This debug mode has nothing to do with the OS debug version.
- Release mode: If release mode is enabled, the application will be directly interrupted when an error occurs. This can protect the system against errors or maliciously attacks.
**Blocklist**
The blocklist specifies the functions or source programs that are not affected by Sanitizer in the module. It prevents benign behavior from being identified as errors or prevents hotspot functions from generating unreasonable and unacceptable overheads. Exercise caution when using this function.
Blocklist example:
```
[cfi]
fun:*([Tt]est|TEST)*
fun: main
[integer]
src:example/*.cpp
```
## Information Collected by the Open Source Software Notice
