diff --git a/en/device-dev/subsystems/subsys-build-FAQ.md b/en/device-dev/subsystems/subsys-build-FAQ.md index 5c335f9ef490da86a481c05e185b74c4315b9de5..6c5b37abf2df7fd3607351c60246243cbce48ca7 100644 --- a/en/device-dev/subsystems/subsys-build-FAQ.md +++ b/en/device-dev/subsystems/subsys-build-FAQ.md @@ -56,18 +56,16 @@ - **Possible Causes** - Permission is required to access files in the RISC-V compiler directory. + You do not have the permission to access files in the RISC-V compiler directory. - **Solution** 1. Run the following command to locate **gcc_riscv32**: - ```shell - which riscv32-unknown-elf-gcc - ``` + ```shell + which riscv32-unknown-elf-gcc + ``` - - 2. Run the **chmod** command to change the directory permission to **755**. ### "No module named 'Crypto'" Displayed During the Build Process diff --git a/en/device-dev/subsystems/subsys-build-all.md b/en/device-dev/subsystems/subsys-build-all.md index 409d27d489fb08f4134c2d371ef32140f272cbe4..8558d43762bf272514031e41483f5571a41d08d4 100644 --- a/en/device-dev/subsystems/subsys-build-all.md +++ b/en/device-dev/subsystems/subsys-build-all.md @@ -10,46 +10,46 @@ The OpenHarmony Compilation and Building subsystem provides a build framework ba ### Application Scope -This guide is applicable to mini, small, and standard systems. The [Chipset Solution](subsys-build-chip_solution.md) applies to mini and small systems. +This guide is applicable to mini, small, and standard systems. The [Chipset Solution](subsys-build-chip_solution.md) applies only to mini and small systems. ### Basic Concepts Learn the following basic concepts before you get started: -- Platform +- Platform A platform consists of a development board and the kernel. The subsystems and components vary with the platform. -- Product +- Product A product is a collection of components. The product image built can run on different development boards. -- Subsystem +- Subsystem OpenHarmony is designed with a layered architecture, which consists of the kernel layer, system service layer, framework layer, and application layer from bottom up. For details, see [OpenHarmony Technical Architecture](https://gitee.com/openharmony#technical-architecture). System functions are built from components, subsystems, and then to the system. In a multi-device deployment, you can customize subsystems and components as required. A subsystem, as a logical concept, consists of the least required components. -- Component +- Component A component is a reusable software binary unit that contains source code, configuration files, resource files, and build scripts. It can be built independently, integrated in binary mode, and tested independently. The chipset solution mentioned in this guide is a special component in nature. -- Module +- Module A module is a target to build. A component can also be a target to build. -- Feature +- Feature A component can provide differentiated functions through features. -- GN +- GN - GN is used to build Ninja files. + GN is used to generate Ninja files. -- Ninja +- Ninja - Ninja is a small high-speed building system. + Ninja is a small high-speed build system. -- hb +- hb hb is an OpenHarmony command line tool used to execute build commands. @@ -88,7 +88,7 @@ A product, component, and module can be built, but a subsystem cannot. The figur ### Constraints -Currently, only Ubuntu18.04 and Ubuntu20.04 are supported (Ubuntu22.04 is not supported). +Currently, only Ubuntu18.04 and Ubuntu20.04 are supported. Ubuntu22.04 is not supported. ### Environment Configuration @@ -104,6 +104,7 @@ You must install the software packages required for build. The command is as fol apt-get update -y apt-get install -y apt-utils binutils bison flex bc build-essential make mtd-utils gcc-arm-linux-gnueabi u-boot-tools python3.9.2 python3-pip git zip unzip curl wget gcc g++ ruby dosfstools mtools default-jre default-jdk scons python3-distutils perl openssl libssl-dev cpio git-lfs m4 ccache zlib1g-dev tar rsync liblz4-tool genext2fs binutils-dev device-tree-compiler e2fsprogs git-core gnupg gnutls-bin gperf lib32ncurses5-dev libffi-dev zlib* libelf-dev libx11-dev libgl1-mesa-dev lib32z1-dev xsltproc x11proto-core-dev libc6-dev-i386 libxml2-dev lib32z-dev libdwarf-dev apt-get install -y grsync xxd libglib2.0-dev libpixman-1-dev kmod jfsutils reiserfsprogs xfsprogs squashfs-tools pcmciautils quota ppp libtinfo-dev libtinfo5 libncurses5 libncurses5-dev libncursesw5 libstdc++6 gcc-arm-none-eabi vim ssh locales doxygen + apt-get install -y libxinerama-dev libxcursor-dev libxrandr-dev libxi-dev # 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**. chmod +x /usr/bin/repo pip3 install --trusted-host https://repo.huaweicloud.com -i https://repo.huaweicloud.com/repository/pypi/simple requests setuptools pymongo kconfiglib pycryptodome ecdsa ohos-build pyyaml prompt_toolkit==1.0.14 redis json2html yagmail python-jenkins @@ -144,7 +145,7 @@ To ensure that chipset and product solutions are decoupled from OpenHarmony, you ├── __pycache__ ├── build_scripts/ # Python scripts for build -├── common/ +├── common/ ├── config/ # Build-related configuration ├── core │ └── gn/ # BUILD.gn configuration @@ -193,40 +194,40 @@ Then, run the build commands in command line (CLI) mode or hb mode. 1. Using the CLI Run the following command in the root directory of the source code to build a full distribution: - - ```Shell - ./build.sh --product-name {product_name} + + ```shell + ./build.sh --product-name {product_name} ``` - + **{product_name}** specifies the product platform supported by the current distribution, for example, **hispark_taurus_standard**. - + The image generated is stored in the **out/{device_name}/packages/phone/images/** directory. - + The **./build.sh** command supports the following options: - + ```shell - -h, --help # Display help information and exit. - --source-root-dir=SOURCE_ROOT_DIR # Specify the path. - --product-name=PRODUCT_NAME # Specify the product name. - --device-name=DEVICE_NAME # Specify the device name. - --target-cpu=TARGET_CPU # Specify the CPU. - --target-os=TARGET_OS # Specify the operating system. - -T BUILD_TARGET, --build-target=BUILD_TARGET # Specify one or more targets to build. - --gn-args=GN_ARGS # Specify GN parameters. - --ninja-args=NINJA_ARGS # Specify Ninja parameters. - -v, --verbose # Display all commands used. - --keep-ninja-going # Keep Ninja going until 1,000,000 jobs fail. - --jobs=JOBS - --export-para=EXPORT_PARA - --build-only-gn # Perform GN parsing and do not run Ninja. - --ccache # (Optional) Use ccache for build. You need to install ccache locally. - --fast-rebuild # Whether to allow fast rebuild. The default value is False. - --log-level=LOG_LEVEL # Specify the log level used in the build process. The options are debug, info, and error. The default value is info. - --device-type=DEVICE_TYPE # Specify the device type. The default value is default. - --build-variant=BUILD_VARIANT #Specifies the device operation mode. The default value is user. + -h, --help # Display help information and exit. + --source-root-dir=SOURCE_ROOT_DIR # Specify the path. + --product-name=PRODUCT_NAME # Specify the product name. + --device-name=DEVICE_NAME # Specify the device name. + --target-cpu=TARGET_CPU # Specify the CPU. + --target-os=TARGET_OS # Specify the operating system. + -T BUILD_TARGET, --build-target=BUILD_TARGET # Specify one or more targets to build. + --gn-args=GN_ARGS # Specify GN parameters. + --ninja-args=NINJA_ARGS # Specify Ninja parameters. + -v, --verbose # Display all commands used. + --keep-ninja-going # Keep Ninja going until 1,000,000 jobs fail. + --jobs=JOBS + --export-para=EXPORT_PARA + --build-only-gn # Perform GN parsing and do not run Ninja. + --ccache # (Optional) Use ccache for build. You need to install ccache locally. + --fast-rebuild # Specify whether to allow fast rebuild. The default value is False. + --log-level=LOG_LEVEL # Specify the log level used in the build process. The options are debug, info, and error. The default value is info. + --device-type=DEVICE_TYPE # Specify the device type. The default value is default. + --build-variant=BUILD_VARIANT # Specify the device operation mode. The default value is user. ``` - + 2. Using the hb tool @@ -234,7 +235,7 @@ Then, run the build commands in command line (CLI) mode or hb mode. **hb set** - Sets the product to build + Sets the product to build. ```shell hb set -h @@ -257,7 +258,7 @@ Then, run the build commands in command line (CLI) mode or hb mode. **hb env** - Displays the current settings. + Displays current settings. ```shell hb env @@ -334,7 +335,7 @@ Then, run the build commands in command line (CLI) mode or hb mode. **hb clean** - Deletes all the files except **args.gn** and **build.log** in the **out** directory. To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/board/product**. By default, the files in the **out** directory are cleared. + 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 @@ -367,4 +368,4 @@ You can add and build a product, component, chipset solution, and module. For de - [deps and external_deps](subsys-build-reference.md#deps-and-external_deps) - [Information Collected by the Open Source Software Notice](subsys-build-reference.md#information-collected-by-the-open-source-software-notice) - [Parameters for Accelerating Local Build](subsys-build-reference.md#parameters-for-accelerating-local-build) -- [Viewing Ninja Build Information](subsys-build-reference.md#viewing-ninja-build-information) \ No newline at end of file +- [Viewing Ninja Build Information](subsys-build-reference.md#viewing-ninja-build-information) diff --git a/en/device-dev/subsystems/subsys-build-chip_solution.md b/en/device-dev/subsystems/subsys-build-chip_solution.md index 79feb1fd059a9715b3da749e10bd198940cf5df5..46476aaa2111fbc0846754b1158af5ca2cc3bcb6 100644 --- a/en/device-dev/subsystems/subsys-build-chip_solution.md +++ b/en/device-dev/subsystems/subsys-build-chip_solution.md @@ -2,21 +2,22 @@ ### Configuration Rules - The chipset solution is a special component. It is built based on a development board, including the drivers, device API adaptation, and SDK. -- The source code path is named in the **device/{Development board}/{Chipset solution vendor}** format. +- The source code path is named in the **device/{Development_board}/{Chipset_solution_vendor}** format. - The chipset solution component is built by default based on the development board selected. -- The chipset solution directory structure is as follows: + +The chipset solution directory structure is as follows: ```shell device └── board - └── company # Chipset solution vendor - └── hispark_aries # Developement board name - ├── BUILD.gn # Build script - ├── hals # OS device API adaptation - ├── linux # (Optional) Linux kernel version - │ └── config.gni # Linux build configuration - └── liteos_a # (Optional) LiteOS kernel version - └── config.gni # LiteOS_A build configuration + └── company # Chipset solution vendor + └── hispark_aries # Development board name + ├── BUILD.gn # Build script + ├── hals # OS device API adaptation + ├── linux # (Optional) Linux kernel version + │ └── config.gni # Linux build configuration + └── liteos_a # (Optional) LiteOS kernel version + └── config.gni # LiteOS_A build configuration ``` ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
The **config.gni** file contains the configuration related to the build of the development board. The parameters in this file are used to compile all OS components and are globally visible during the build process. @@ -28,7 +29,7 @@ kernel_version: Kernel version of the development board, for example, 4.19. board_cpu: CPU of the development board, for example, Cortex-A7 or RISCV32. board_arch: Chipset architecture of the development board, for example, ARMv7-A or RV32IMAC. - board_toolchain: Name of the customized build toolchain used by the development board, for example, gcc-arm-none-eabi. If this field is not specified, ohos-clang will be used by default. + board_toolchain: Name of the customized build toolchain used by the development board, for example, gcc-arm-none-eabi. If this field is not specified, ohos-clang will be used. board_toolchain_prefix: Prefix of the toolchain, for example, gcc-arm-none-eabi. board_toolchain_type: Toolchain type. Currently, only GCC and clang are supported. board_cflags: Build options of the .c file configured for the development board. @@ -40,13 +41,19 @@ The following uses the RTL8720 development board provided by Realtek as an example. The procedure is as follows: -1. Create a directory for the chipset solution.
Run the following command in the root code directory: +1. Create a directory for the chipset solution. + + Run the following command in the root code directory: ```shell mkdir -p device/board/realtek/rtl8720 ``` -2. Create a directory for kernel adaptation and configure the **config.gni** file of the development board.
For example, to adapt the LiteOS-A kernel to the RTL8720 development board, configure the **device/realtek/rtl8720/liteo_a/config.gni** file as follows: + + +2. Create a directory for kernel adaptation and configure the **config.gni** file of the development board. + + For example, to adapt the LiteOS-A kernel to the RTL8720 development board, configure the **device/board/realtek/rtl8720/liteo_a/config.gni** file as follows: ```shell # Kernel type, e.g. "linux", "liteos_a", "liteos_m". @@ -83,13 +90,18 @@ The following uses the RTL8720 development board provided by Realtek as an examp board_ld_flags = [] ``` -3. Write the build script.
Create the **BUILD.gn** file in the development board directory. The target name must be the same as that of the development board. The following is an example of the **device/board/realtek/rtl8720/BUILD.gn** file for the RTL8720 development board: +3. Write the build script. + + Create the **BUILD.gn** file in the development board directory. The target name must be the same as that of the development board. The following is an example of the **device/board/realtek/rtl8720/BUILD.gn** file for the RTL8720 development board: ```shell group("rtl8720") { # The build target can be shared_library, static_library, or an executable file. # Content - ...... + ... } ``` -4. Build the chipset solution.
Run the **hb build** command in the development board directory to start the build. +4. Build the chipset solution. + + Run the **hb build** command in the development board directory to start the build. + diff --git a/en/device-dev/subsystems/subsys-build-component.md b/en/device-dev/subsystems/subsys-build-component.md index a9ba2d6738c752671a872d0f5f527362596dc7a6..e8ec83add39391102c02c06f73d2e52667d01cb0 100644 --- a/en/device-dev/subsystems/subsys-build-component.md +++ b/en/device-dev/subsystems/subsys-build-component.md @@ -12,7 +12,7 @@ The **bundle.json** file of a component is stored in the root directory of the c "publishAs": "code-segment", # HPM package release mode. The default value is code-segment. "segment": { "destPath": "" - }, # Code restoration path (source code path) set when publishAs is code-segment. + }, # Code restoration path (source code path) set when publishAs is code-segment. "dirs": {"base/sensors/sensor_lite"}, # Directory structure of the HPM package. This field is mandatory and can be left empty. "scripts": {}, # Scripts to be executed. This field is mandatory and can be left empty. "licensePath": "COPYING", @@ -22,9 +22,9 @@ The **bundle.json** file of a component is stored in the root directory of the c "component": { # Component attributes. "name": "sensor_lite", # Component name. "subsystem": "", # Subsystem to which the component belongs. - "syscap": [], # System capabilities provided by the component for applications. - "features": [], # List of external configurable features of a component. Generally, this parameter corresponds to sub_component in build. - "adapted_system_type": [], # Types of adapted systems, which can be mini, small, and standard. + "syscap": [], # System capabilities provided by the component for applications. + "features": [], # List of external configurable features of the component. Generally, this parameter corresponds to sub_component in build. + "adapted_system_type": [], # Types of adapted systems, which can be mini, small, standard, or their combinations. "rom": "92KB", # Component ROM size. "ram": "~200KB", # Component RAM size. "deps": { @@ -36,11 +36,11 @@ The **bundle.json** file of a component is stored in the root directory of the c "bounds_checking_function" ] } - "build": { # Build-related configurations. + "build": { # Build-related configurations. "sub_component": [ ""//base/sensors/sensor_lite/services:sensor_service"", # Component build entry. - ], # Component build entry. Configure modules here. - "inner_kits": [], # APIs between components. + ], # Component build entry. Configure modules here. + "inner_kits": [], # APIs between components. "test": [] # Entry for building the component's test cases. } } @@ -56,7 +56,7 @@ component │ └── kits # APIs provided for application developers ├── frameworks # Framework implementation ├── services # Service implementation -├── BUILD.gn # Build script +├── BUILD.gn # Build script ``` You need to configure the component name, source code path, function description, mandatory or not, build target, RAM, ROM, output, adapted kernel, configurable features, and dependencies. @@ -65,7 +65,9 @@ When adding a component, you must add the component definition to the JSON file ### Adding and Building a Component -1. Add a component.
The following use a custom component as an example to describe how to compile a library, executable file, and configuration file. +1. Add a component. + + The following use a custom component as an example to describe how to compile a library, executable file, and configuration file. In this example, **partA** consists of **feature1**, **feature2**, and **feature3**, which represent a dynamic library, an executable file, and an etc configuration file, respectively. @@ -121,7 +123,7 @@ When adding a component, you must add the component definition to the JSON file deps = [ # Dependent modules in the component "../feature1:helloworld_lib" ] - external_deps = [ "partB:module1" ] # (Optional) Dependent modules of another component are named in the Component name:Module name format. + external_deps = [ "partB:module1" ] # (Optional) Dependent modules of another component are named in the Component name:Module name format. install_enable = true # By default, executable programs are not installed. Set this parameter to true if an executable program needs to be installed. part_name = "partA" } @@ -139,13 +141,15 @@ When adding a component, you must add the component definition to the JSON file (d) Add the module configuration **test/examples/bundle.json** to the **bundle.json** file of the component. Each component has a **bundle.json** file in the root directory of the component. For details, see the [component bundle.json file](subsys-build-component.md#configuration-rules). -2. Add the component to **//vendor/{*product_company*}/{*product-name*}/config.json**. +2. Add the component to **//vendor/{*product_company*}/{*product_name*}/config.json**. + + For example, add "subsystem_examples:partA" to the product **config.json** file. Then, **partA** will be built and packaged into the distribution. - For example, after you add "subsystem_examples:partA" to the product **config.json** file, **partA** will be built and packaged into the distribution. +3. Start the build. -3. Start the build.
You can start the build by using the [CLI or hb tool](subsys-build-all.md#build-commands). The following uses the CLI as an example: + You can start the build by using the [CLI or hb tool](subsys-build-all.md#build-commands). The following uses the CLI as an example: - You can run **--build-target** *Component name* to build a component separately. For example, to build the musl component of hispark_taurus_standard, run the following command: + You can run '--build-target componentName' to build a component separately. For example, to build the musl component of hispark_taurus_standard, run the following command: ``` ./build.sh --product-name hispark_taurus_standard --build-target musl --ccache @@ -157,4 +161,6 @@ When adding a component, you must add the component definition to the JSON file ./build.sh --product-name hispark_taurus_standard --ccache ``` -4. Obtain the build result.
You can obtain the generated files from the **out/hispark_taurus/** directory and the image in the **out/hispark_taurus/packages/phone/images/** directory. +4. Obtain the build result. + + You can obtain the generated files from the **out/hispark_taurus/** directory and the image in the **out/hispark_taurus/packages/phone/images/** directory. diff --git a/en/device-dev/subsystems/subsys-build-feature.md b/en/device-dev/subsystems/subsys-build-feature.md index 7e85920c8675d53f0c092ea70648580cd8454233..a9ea472f48d49510a64348a8f83b9f6d5868429d 100644 --- a/en/device-dev/subsystems/subsys-build-feature.md +++ b/en/device-dev/subsystems/subsys-build-feature.md @@ -1,11 +1,11 @@ # Feature ### Configuration Rules -This document describes how to declare, define, and configure features. +This document describes how to declare, define, and use features. - Declare a feature - Declare the features of a component in **feature_list** of the **bundle.json** file of the component. Each feature must start with the **{component name}**. + Declare the features of a component in **feature_list** of the **bundle.json** file of the component. Each feature must start with the **{component_name}**. The following is an example: @@ -34,11 +34,11 @@ This document describes how to declare, define, and configure features. } ``` - The value defined is the default value of the component. The product can overload the feature default values in the component list. + The value defined is the default value of the feature for this component. The product can overload the feature default values in the component list. If a feature is used by multiple modules of a component, you are advised to define the feature in the global .gni file of the component and import the .gni file to the **BUILD.gn** file of each module. -- Configure a feature +- Use a feature In the **BUILD.gn** file, determine the code or modules to build based on features. @@ -53,7 +53,7 @@ This document describes how to declare, define, and configure features. external_deps += [ "xxx" ] } - # The bundle.json file does not support the if statement. If the sub_component contained in the bundle.json file needs to be deleted, define group(). + # The **bundle.json** file does not support the if statement. If the sub_component contained in the **bundle.json** file needs to be deleted, define group(). group("testGroup") { deps = [] if ({partName}_feature_A) { diff --git a/en/device-dev/subsystems/subsys-build-module.md b/en/device-dev/subsystems/subsys-build-module.md index 94e3ab52a45a581adaf565ec969d7c9835d350bf..039c58593f81732fb406b99f9a8a2c7f0f9be291 100644 --- a/en/device-dev/subsystems/subsys-build-module.md +++ b/en/device-dev/subsystems/subsys-build-module.md @@ -1,7 +1,7 @@ # Module ## Configuration Rules -The Compilation and Building subsystem implements compilation and packaging by module, component, and product. A module is an target to build. It can be a dynamic library, static library, configuration file, or prebuilt module. The component to which a module belongs must be defined. A module can belong to only one component. OpenHarmony uses customized GN templates to configure modules. For details about the GN basics, see https://gn.googlesource.com/gn/+/main/docs/reference.md. +The Compilation and Building subsystem implements compilation and packaging by module, component, and product. A module is an target to build. It can be a dynamic library, static library, configuration file, or prebuilt module. A module must belong to a component and can belong to only one component. OpenHarmony uses customized GN templates to configure modules. For details about the GN basics, see https://gn.googlesource.com/gn/+/main/docs/reference.md. The common templates for module configuration are as follows: @@ -12,22 +12,22 @@ ohos_static_library ohos_executable ohos_source_set -# # Prebuilt templates +# Prebuilt templates ohos_prebuilt_executable ohos_prebuilt_shared_library ohos_prebuilt_static_library -#HAP templates +# HAP templates ohos_hap ohos_app_scope ohos_js_assets ohos_resources -#Other templates -#Configuration file +# Other templates +# Configuration file ohos_prebuild_etc -#SA profile +# SA profile ohos_sa_profile ``` @@ -52,13 +52,13 @@ ohos_shared_library("helloworld") { deps = [] # Define dependent modules that belong to the same component. external_deps = [ # Define dependent modules that belong to different components. - "part_name:module_name", # The value is in the Component name:Module name format. - ] # The dependent module must be declared in inner_kits by the dependent component. + "part_name:module_name", # The value is in the Component_name:Module_name format. + ] # The dependent modules must be declared in inner_kits by the dependent component. output_name = [string] # Name of the module output. output_extension = [] # Extension name of the module. module_install_dir = [] # Module installation directory. The default directory is /system/lib64 or /system/lib. Specify the directory from system/ or vendor/. - relative_install_dir = [] # Relative installation directory of the module (relative to /system/lib64 or /system/lib). If module_install_dir is configured, the parameter does not take effect. + relative_install_dir = [] # Relative module installation directory (relative to /system/lib64 or /system/lib). If module_install_dir is configured, the parameter does not take effect. part_name = [string] # (Mandatory) Component name. output_dir @@ -84,7 +84,7 @@ ohos_shared_library("helloworld") { } ``` -**ohos_static_library** example +**ohos_static_library** example: ```shell import("//build/ohos.gni") @@ -98,8 +98,8 @@ ohos_static_library("helloworld") { cflags = [] external_deps = [ # Define dependent modules that belong to different components. - "part_name:module_name", # The value is in the Component name:Module name format. - ] # The dependent module must be declared in inner_kits by the dependent component. + "part_name:module_name", # The value is in the Component_name:Module_name format. + ] # The dependent modules must be declared in inner_kits by the dependent component. lib_dirs = [] public_configs = [] @@ -131,8 +131,8 @@ ohos_executable("helloworld") { deps = [] # Define dependent modules that belong to the same component. external_deps = [ # Define dependent modules that belong to different components. - "part_name:module_name", # The value is in the Component name:Module name format. - ] # The dependent module must be declared in inner_kits by the dependent component. + "part_name:module_name", # The value is in the Component_name:Module_name format. + ] # The dependent modules must be declared in inner_kits by the dependent component. ohos_test = [] test_output_dir = [] @@ -160,7 +160,7 @@ ohos_executable("helloworld") { } ``` -**ohos_source_set** example +**ohos_source_set** example: ```shell import("//build/ohos.gni") @@ -173,11 +173,11 @@ ohos_source_set("helloworld") { public_configs = [] part_name = [string] # Component name. subsystem_name = [string] # Subsystem name. - deps = [] # Define dependent modules that belong to the same component. + deps = [] # Define dependent modules that belong to the same component. external_deps = [ # Define dependent modules that belong to different components. - "part_name:module_name", # The value is in the Component name:Module name format. - ] # The dependent module must be declared in inner_kits by the dependent component. + "part_name:module_name", # The value is in the Component_name:Module_name format. + ] # The dependent modules must be declared in inner_kits by the dependent component. # Sanitizer variables cfi = [boolean] @@ -192,7 +192,7 @@ ohos_source_set("helloworld") { license_file = [] remove_configs = [] no_default_deps = [] - license_file = [] # A .txt file. + license_file = [] # A .txt file. license_as_sources = [] use_exceptions = [] } @@ -204,63 +204,63 @@ ohos_source_set("helloworld") { The .gni file of the prebuilt templates is located in **openharmony/build/templates/cxx/prebuilt.gni**. -**ohos_prebuilt_executable** example +**ohos_prebuilt_executable** example: ```shell import("//build/ohos.gni") ohos_prebuilt_executable("helloworld") { - sources = ["file"] # Source. + sources = ["file"] # Source. output = [] install_enable = [boolean] - deps = [] # Define dependent modules that belong to the same component. + deps = [] # Define dependent modules that belong to the same component. public_configs = [] - subsystem_name = [string] # Subsystem name. - part_name = [string] # Component name. + subsystem_name = [string] # Subsystem name. + part_name = [string] # Component name. testonly = [boolean] visibility = [] install_images = [] - module_install_dir = [] # Module installation directory, starting from system/ or vendor/. - relative_install_dir = [] # Relative module installation directory (relative to system/etc). If module_install_dir is configured, the parameter does not take effect. + module_install_dir = [] # Module installation directory, starting from system/ or vendor/. + relative_install_dir = [] # Relative module installation directory (relative to system/etc). If module_install_dir is configured, the parameter does not take effect. symlink_target_name = [] - license_file = [] # A .txt file. + license_file = [] # A .txt file. license_as_sources = [] } ``` -**ohos_prebuilt_shared_library** example +**ohos_prebuilt_shared_library** example: ```shell import("//build/ohos.gni") ohos_prebuilt_shared_library("helloworld") { - sources = ["file"] # .so files. + sources = ["file"] # .so files. output = [] install_enable = [boolean] - deps = [] # Define dependent modules that belong to the same component. + deps = [] # Define dependent modules that belong to the same component. public_configs = [] - subsystem_name = [string] # Subsystem name. - part_name = [string] # Component name. + subsystem_name = [string] # Subsystem name. + part_name = [string] # Component name. testonly = [boolean] visibility = [] install_images = [] - module_install_dir = [] # Module installation directory, starting from system/ or vendor/. - relative_install_dir = [] # Relative module installation directory (relative to system/etc). If module_install_dir is configured, the parameter does not take effect. + module_install_dir = [] # Module installation directory, starting from system/ or vendor/. + relative_install_dir = [] # Relative module installation directory (relative to system/etc). If module_install_dir is configured, the parameter does not take effect. symlink_target_name = [string] - license_file = [string] # A .txt file. + license_file = [string] # A .txt file. license_as_sources = [] } ``` -**ohos_prebuilt_static_library** example +**ohos_prebuilt_static_library** example: ```shell import("//build/ohos.gni") @@ -348,40 +348,40 @@ The figure below illustrates the process for adding a module. A module belongs t ```shell { - "name": "@ohos/, # HPM component name, in the "@Organization/Component name" format. - "description": "xxxxxxxxxxxxxxxxxxx", # Description of the component functions. - "version": "3.1", # Version, which must be the same as the version of OpenHarmony. - "license": "MIT", # Component license. - "publishAs": "code-segment", # HPM package release mode. The default value is code-segment. + "name": "@ohos/, # HPM component name, in the "@Organization/Component_name" format. + "description": "xxxxxxxxxxxxxxxxxxx", # Description of the component functions. + "version": "3.1", # Version, which must be the same as the version of OpenHarmony. + "license": "MIT", # Component license. + "publishAs": "code-segment", # HPM package release mode. The default value is code-segment. "segment": { "destPath": "third_party/nghttp2" - }, # Code restoration path (source code path) set when publishAs is code-segment. - "dirs": {}, # Directory structure of the HPM package. This field is mandatory and can be left empty. - "scripts": {}, # Scripts to be executed. This field is mandatory and can be left empty. + }, # Code restoration path (source code path) set when publishAs is code-segment. + "dirs": {}, # Directory structure of the HPM package. This field is mandatory and can be left empty. + "scripts": {}, # Scripts to be executed. This field is mandatory and can be left empty. "licensePath": "COPYING", "readmePath": { "en": "README.rst" }, - "component": { # Component attributes. - "name": "", # Component name. - "subsystem": "", # Subsystem to which the component belongs. - "syscap": [], # System capabilities provided by the component for applications. - "features": [], # List of configurable features of the component. Generally, this parameter corresponds to sub_component in build. - "adapted_system_type": [], # Types of adapted systems. The value can be mini, small, and standard. - "rom": "xxxKB" # ROM baseline. If there is no baseline, enter the current value. - "ram": "xxxKB", # RAM baseline. If there is no baseline, enter the current value. + "component": { # Component attributes. + "name": "", # Component name. + "subsystem": "", # Subsystem to which the component belongs. + "syscap": [], # System capabilities provided by the component for applications. + "features": [], # List of configurable features of the component. Generally, this parameter corresponds to sub_component in build. + "adapted_system_type": [], # Types of adapted systems. The value can be mini, small, standard, or their combinations. + "rom": "xxxKB" # ROM baseline. If there is no baseline, enter the current value. + "ram": "xxxKB", # RAM baseline. If there is no baseline, enter the current value. "deps": { - "components": [ # Other components on which this component depends. - "third_party": [ # Third-party open-source software on which this component depends. + "components": [ # Other components on which this component depends. + "third_party": [ # Third-party open-source software on which this component depends. }, - "build": { # Build-related configuration + "build": { # Build-related configuration. "sub_component": [ - "//foundation/arkui/napi:napi_packages", # Existing module 1 - "//foundation/arkui/napi:napi_packages_ndk" # Existing module 2 - "//foundation/arkui/napi:new" # Module to add + "//foundation/arkui/napi:napi_packages", # Existing module 1. + "//foundation/arkui/napi:napi_packages_ndk" # Existing module 2. + "//foundation/arkui/napi:new" # Module to add. ], # Component build entry. Configure the module here. - "inner_kits": [], # APIs between components + "inner_kits": [], # APIs between components. "test": [] # Entry for building the component's test cases. } } @@ -398,16 +398,16 @@ The figure below illustrates the process for adding a module. A module belongs t 2. Create a **bundle.json** file in the folder of the corresponding subsystem. -3. Add the new component to the end of existing components in **vendor/{product_company}/{product-name}/config.json**. +3. Add the new component to the end of existing components in **vendor/{product_company}/{product_name}/config.json**. ```shell "subsystems": [ { "subsystem": "Subsystem to which the component belongs", "components": [ - {"component": "Component 1 name", "features":[]}, # Existing component 1 in the subsystem - { "component": "Component 2 name", "features":[] }, # Existing component 2 in the subsystem - {"component": "New component name", "features":[]} # New component in the subsystem + {"component": "Component 1 name", "features":[]}, # Existing component 1 in the subsystem + { "component": "Component 2 name", "features":[] }, # Existing component 2 in the subsystem + {"component": "New component name", "features":[]} # New component in the subsystem ] }, . @@ -419,9 +419,9 @@ The figure below illustrates the process for adding a module. A module belongs t **Creating a Subsystem and Adding a Module** -1. Configure the **BUILD.gn** file in the module directory and select the corresponding GN template. This step is the same as the step in "Creating a Component and Adding a Module." +1. Configure the **BUILD.gn** file in the module directory and select the corresponding GN template. This step is the same as Step 1 in "Creating a Component and Adding a Module." -2. Create a **bundle.json** file in the folder of the component of the subsystem. This step is the same as the step in "Creating a Component and Adding a Module." +2. Create a **bundle.json** file in the folder of the component of the subsystem. This step is the same as Step 2 in "Creating a Component and Adding a Module." 3. Modify the **subsystem_config.json** file in the **build** directory. @@ -445,7 +445,7 @@ The figure below illustrates the process for adding a module. A module belongs t The **subsystem_config.json** file defines the subsystems and their directories. When adding a subsystem, specify **path** and **name** for the subsystem. -4. If **product-name** in the **vendor/{product_company}/{product-name}** directory is **hispark_taurus_standard**, add the new component information to the end of existing components in the **config.json** file. +4. If **product_name** in the **vendor/{product_company}/{product_name}** directory is **hispark_taurus_standard**, add the new component information to the end of existing components in the **config.json** file. ```shell "subsystems": [ @@ -481,25 +481,25 @@ The figure below illustrates the process for adding a module. A module belongs t 4. Start the build and check whether a .so file or binary file is generated. - **Building a Module** You can start the build by using the [CLI or hb tool](subsys-build-all.md#build-commands). The following uses the CLI as an example: - You can run the **--build-target** *Module name* command to build a module separately. +You can run the **--build-target** *Module_name* command to build a module separately. - ```shell - ./build.sh --build-target Module Name - ``` +```shell +./build.sh --build-target Module_name +``` - You can also build a product. For example, to build hispark_taurus_standard, run the following command: +You can also build a product. For example, to build hispark_taurus_standard, run the following command: - ```shell - ./build.sh --product-name hispark_taurus_standard --build-target Module name --ccache - ``` +```shell +./build.sh --product-name hispark_taurus_standard --build-target Module_name --ccache +``` - You can also build the component to which the module belongs. +You can also build the component to which the module belongs. + +```shell +./build.sh --product-name hispark_taurus_standard --build-target musl --build-target Module_name --ccache +``` - ```shell - ./build.sh --product-name hispark_taurus_standard --build-target musl --build-target Module name --ccache - ``` diff --git a/en/device-dev/subsystems/subsys-build-product.md b/en/device-dev/subsystems/subsys-build-product.md index f0f2158a617e31be0bd3527cbb786dec22dec3db..1ef4c244a18c589b3efd5bfb210af7e9c2effb2f 100644 --- a/en/device-dev/subsystems/subsys-build-product.md +++ b/en/device-dev/subsystems/subsys-build-product.md @@ -1,7 +1,7 @@ # Product ### Configuration Rules -The product solution is a special component. It is a product built based on a development board. It includes the OS adaptation, component assembly and configuration, startup configuration, and file system configuration. The source code path of a product solution is in the **vendor/{Product solution vendor}/{Product name}** format. +The product solution is a special component. It is a product built based on a development board. It includes the OS adaptation, component assembly and configuration, startup configuration, and file system configuration. The source code path of a product solution is in the **vendor/{Product_solution_vendor}/{Product_name}** format. The product solution directory structure is as follows: @@ -23,7 +23,7 @@ vendor The key directories and files are described as follows: -1. **vendor/company/product/init_configs/etc**
This folder contains the rcS, Sxxx, and fstab scripts. The init process runs the rcS, fstab, and S00-xxx scripts in sequence before starting system services. The **S***xxx* script is used to create device nodes and directories, scan device nodes, and change file permissions for the development board and product. These scripts are copied from the **BUILD.gn** file to the **out** directory of the product as required and packaged into the **rootfs** image. +1. **vendor/company/product/init_configs/etc**
This folder contains the rcS, Sxxx, and fstab scripts. The init process runs the rcS, fstab, and S00xxx scripts in sequence before starting system services. The Sxxx script is used to create device nodes and directories, scan device nodes, and change file permissions for the development board and product. These scripts are copied from the **BUILD.gn** file to the **out** directory of the product as required and packaged into the **rootfs** image. 2. **vendor/company/product/init_configs/init.cfg**
**init.cfg** defines how the init process starts services. Currently, the following commands can be parsed: @@ -41,21 +41,21 @@ The key directories and files are described as follows: ```shell { - "jobs" : [{ # An array of Jobs. A job corresponds to a command set. Jobs are executed in the following sequence: pre-init > init > post-init. + "jobs" : [{ # An array of jobs. A job corresponds to a command set. Jobs are executed in the following sequence: pre-init > init > post-init. "name" : "pre-init", "cmds" : [ "mkdir /storage/data", # Create a directory. "chmod 0755 /storage/data", # Modify the permissions. The format of the permission value is 0xxx, for example, 0755. "mkdir /storage/data/log", "chmod 0755 /storage/data/log", - "chown 4 4 /storage/data/log", # Change the owner group. The first number is the user ID (UID), and the second number is the group ID (GID). + "chown 4 4 /storage/data/log", # Change the owner group. The first number is the user ID (UID), and the second number is the group ID (GID). ...... "mount vfat /dev/mmcblock0 /sdcard rw,umask=000" # The command format is mount [File system type] [source] [target] [flags] [data]. - # The value of flags can be nodev, noexec, nosuid, or rdonly only. + # The value of flags can be nodev, noexec, nosuid, or rdonly. ] }, { "name" : "init", - "cmds" : [ # Start services based on the sequence of the cmds array. + "cmds" : [ # Start services based on the sequence in the cmds array. "start shell", # There is only one space between start and the service name. ...... "start service1" @@ -70,7 +70,7 @@ The key directories and files are described as follows: "path" : ["/sbin/getty", "-n", "-l", "/bin/sh", "-L", "115200", "ttyS000", "vt100"], # Full path of the executable file. It must start with "path". "uid" : 0, # Process UID, which must be the same as that in the binary file. "gid" : 0, # Process GID, which must be the same as that in the binary file. - "once" : 0, # Whether the process is a one-off process. The value 1 indicates that process is a one-off process, and the value 0 indicates the opposite. The init process does not restart the one-off process after the process exits. + "once" : 0, # Whether the process is a one-off process. The value 1 indicates a one-off process, and the value 0 indicates the opposite. The init process does not restart the one-off process after the process exits. "importance" : 0, # Whether the process is a key process. The value 1 indicates a key process, and the value 0 indicates the opposite. If a key process exits, the init process will restart the board. "caps" : [4294967295] }, @@ -88,7 +88,7 @@ The key directories and files are described as follows: ```shell { "product_name": "ipcamera", # Product name - "version": "3.0", # Version of config.json. The value is 3.0. + "version": "3.0", # Version of config.json. The value must be 3.0. "type": "small", # System type. The value can be mini, small, or standard. "ohos_version": "OpenHarmony 1.0", # OS version "device_company": "hisilicon", # Chipset vendor @@ -114,30 +114,30 @@ The key directories and files are described as follows: 5. **vendor/company/product/fs.yml**
The **fs.yml** file defines the process for creating a file system image, for example, **rootfs.img** (user-space root file system) and **userfs.img** (readable and writable file). It consists of multiple lists, and each list corresponds to a file system. The fields are described as follows: ```shell - fs_dir_name: (Mandatory) specifies name of the file system, for example, rootfs or userfs. - fs_dirs: (Optional) specifies the mapping between the file directory in the out directory and the system file directory. Each file directory corresponds to a list. - source_dir: (Optional) specifies target file directory in the out directory. If this field is not specified, an empty directory will be created in the file system based on target_dir. - target_dir: (Mandatory) specifies the file directory in the file system. - ignore_files: (Optional) declares ignored files during the copy operation. - dir_mode: (Optional) specifies the file directory permissions. The default value is 755. - file_mode: (Optional) specifies the permissions of all files in the directory. The default value is 555. - fs_filemode: (Optional) specifies the files that require special permissions. Each file corresponds to a list. - file_dir: (Mandatory) specifies the detailed file path in the file system. - file_mode: (Mandatory) declares file permissions. - fs_symlink: (Optional) specifies the soft link of the file system. - fs_make_cmd: (Mandatory) creates the file system script. The script provided by the OS is located in the build/lite/make_rootfs directory. Linux, LiteOS, ext4, jffs2, and vfat are supported. Chipset vendors can also customize the script as required. - fs_attr: (Optional) dynamically adjusts the file system based on configuration items. + fs_dir_name: (mandatory) specifies the name of the file system, for example, rootfs or userfs. + fs_dirs: (optional) specifies the mapping between the file directory in the out directory and the system file directory. Each file directory corresponds to a list. + source_dir: (optional) specifies the target file directory in the out directory. If this field is not specified, an empty directory will be created in the file system based on target_dir. + target_dir: (mandatory) specifies the file directory in the file system. + ignore_files: (optional) declares ignored files during the copy operation. + dir_mode: (optional) specifies the file directory permissions. The default value is 755. + file_mode: (optional) specifies the permissions of all files in the directory. The default value is 555. + fs_filemode: (optional) specifies the files that require special permissions. Each file corresponds to a list. + file_dir: (mandatory) specifies the detailed file path in the file system. + file_mode: (mandatory) declares file permissions. + fs_symlink: (optional) specifies the soft link of the file system. + fs_make_cmd: (mandatory) creates the file system script. The script provided by the OS is located in the build/lite/make_rootfs directory. Linux, LiteOS, ext4, jffs2, and vfat are supported. Chipset vendors can also customize the script as required. + fs_attr: (optional) dynamically adjusts the file system based on configuration items. ``` The **fs_symlink** and **fs_make_cmd** fields support the following variables: - - Code root directory, which corresponds to **${ohos_root_path}** of GN. - - **out** directory of the product, which corresponds to **${root_out_dir}** of GN. - - File system directory ${fs_dir}, which consists variables ${root_path} and ${fs_dir_name}. + - Code root directory, which corresponds to **{ohos_root_path}** of GN. + - **out** directory of the product, which corresponds to **{root_out_dir}** of GN. + - File system directory **${fs_dir}**, which consists of variables **${root_path}** and **${fs_dir_name}**. > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
**fs.yml** is optional. You do not need to configure it for devices without a file system. -6. **vendor/company/product/BUILD.gn**
**BUILD.gn** provides the entry for product build. It is used to compile the source code of the solution vendor and copy the startup configuration file. The **BUILD.gn** file in the corresponding product directory will be compiled by default if a product is selected. The following is an example of the **BUILD.gn** file of a product: +6. **vendor/company/product/BUILD.gn**
**BUILD.gn** provides the entry for product build. It is used to compile the source code of the solution vendor and copy the startup configuration file. The **BUILD.gn** file in the corresponding product directory will be built by default if a product is selected. The following is an example of the **BUILD.gn** file of a product: ```shell group("product") { # The name must be the same as the product name (level-3 directory name under the product directory). @@ -149,7 +149,7 @@ The key directories and files are described as follows: ### Adding and Building a Product -You can customize a product solution by flexibly assembling a chipset solution and components. The procedure is as follows: +You can customize a product solution by assembling any chipset solution and components. The procedure is as follows: 1. Create a directory for the product.
The following uses the Wi-Fi IoT module on the RTL8720 development board as an example.
Run the following command in the root directory of the code: @@ -157,12 +157,12 @@ You can customize a product solution by flexibly assembling a chipset solution a mkdir -p vendor/my_company/wifiiot ``` -2. Configure the product.
Create a **config.json** file, for example for wifiiot, in the product directory.
The **vendor/my_company/wifiiot/config.json** file is as follows: +2. Configure the product.
Create a **config.json** file for the product (for example, wifiiot) in the product directory.
The **vendor/my_company/wifiiot/config.json** file is as follows: ```shell { "product_name": "wifiiot", # Product name - "version": "3.0", # Version of config.json. The value is 3.0. + "version": "3.0", # Version of config.json. The value must be 3.0. "type": "small", # System type. The value can be mini, small, or standard. "ohos_version": "OpenHarmony 1.0", # OS version "device_company": "realtek", # Name of the chipset solution vendor @@ -186,7 +186,7 @@ You can customize a product solution by flexibly assembling a chipset solution a ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
Before the build, the Compilation and Building subsystem checks the validity of the fields in **config.json**. The **device_company**, **board**, **kernel_type**, and **kernel_version** fields must match the chipset solution, and the **subsystem** and **component** fields must match the component description in **build/lite/components**. -3. Implement OS adaptation APIs. Create the **hals** directory in the product directory and save the source code as well as the build script for OS adaptation in this directory. +3. Implement OS adaptation APIs. Create the **hals** directory in the product directory and save the source code as well as the build script for OS adaptation in the **hals** directory. 4. Create the **init_configs** directory in the product directory and then the **init.cfg** file in the **init_configs** directory, and configure the system services to be started. @@ -206,7 +206,7 @@ You can customize a product solution by flexibly assembling a chipset solution a - Test.bin - TestSuite.bin - - # Copy the files in the out/my_board/my_product/libs directory to the rootfs/lib directory, ignore all .a files, and set the file permissions to 644 and folder permissions 755. + # Copy the files in the out/my_board/my_product/libs directory to the rootfs/lib directory, ignore all .a files, and set the file permissions to 644 and folder permissions to 755. source_dir: libs target_dir: lib ignore_files: @@ -299,7 +299,7 @@ You can customize a product solution by flexibly assembling a chipset solution a ```shell # Directory in which the patch is to be installed foundation/communication/dsoftbus: - # Directory in which the patch is stored. + # Directory in which the patch is stored - foundation/communication/dsoftbus/1.patch - foundation/communication/dsoftbus/2.patch third_party/wpa_supplicant: @@ -315,14 +315,14 @@ You can customize a product solution by flexibly assembling a chipset solution a hb build -f --patch ``` -8. Write the build script.
Create a **BUILD.gn** file in the product directory and write the script. The following **BUILD.gn** file uses the Wi-Fi IoT module in step 1 as an example: +8. Write the build script.
Create a **BUILD.gn** file in the product directory and write the script. The following **BUILD.gn** file uses the Wi-Fi IoT module in Step 1 as an example: ```shell group("wifiiot") { # The target name must be the same as the product name. deps = [] deps += [ "init_configs" ] # Copy init configuration. deps += [ "hals" ] # Add hals. - ... # Others + ... # Others } ``` diff --git a/en/device-dev/subsystems/subsys-build-reference.md b/en/device-dev/subsystems/subsys-build-reference.md index 83a8c670244aa58b1f9bd56ada834a77ac54efd0..c5c8017f9d2013069fb7230f450f51ebeba5eade 100644 --- a/en/device-dev/subsystems/subsys-build-reference.md +++ b/en/device-dev/subsystems/subsys-build-reference.md @@ -2,7 +2,7 @@ ## deps and external_deps -When adding a module, you need to declare its dependencies in **BUILD.gn**. **deps** specifies dependent modules in the same component, and **external_deps** specifies dependent modules between components. +When adding a module, you must declare its dependencies in **BUILD.gn**. **deps** specifies dependent modules in the same component, and **external_deps** specifies dependent modules between components. **Dependency Types** @@ -10,7 +10,7 @@ When adding a module, you need to declare its dependencies in **BUILD.gn**. **de The dependency between modules can be classified into **desp** (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 modules 1 and 2 belong to the samp component. +- **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. - **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. @@ -33,7 +33,7 @@ The dependency between modules can be classified into **desp** (left in the figu "GN target of module 1", ... ] # Intra-component dependency - part_name = "part1" # (Mandatory) Name of the component to which the module belongs. + part_name = "part1" # (Mandatory) Name of the component to which the module belongs. } ``` @@ -55,12 +55,12 @@ The dependency between modules can be classified into **desp** (left in the figu external_deps = [ "part1:module1", ... - ] # Inter-component dependency. The dependent module must be declared in **inner_kits** by the dependent component. + ] # 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. } ``` - ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
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**. + ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
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**. ## Information Collected by the Open Source Software Notice @@ -70,7 +70,7 @@ An open source software notice is a file related to the project open source. It The notice collects only the licenses of the modules packaged in the image. For example, the licenses of the tools (such as Clang, Python, and Ninja) used during the build process are not collected. -A static library itself is not packaged. However, if it is packaged into the system as part of a dynamic library or executable file, the license of the static library will be collected for completeness. +A static library itself is not packaged. However, if it is packaged into the system as part of a dynamic library or an executable file, the license of the static library will be collected for completeness. The final **Notice.txt** file must include all licenses used by the files in the image and the mapping between modules and licenses. @@ -92,14 +92,14 @@ Licenses are collected by priority, which ranges from 1 to 4 in descending order 2. If there is no explicitly declared license, the build script searches for the **Readme.OpenSource** file in the directory of **BUILD.gn**, parses the file, and collects the obtained licenses. If the **Readme.OpenSource** file does not contain license information, an error will be reported. -3. If the **Readme.OpenSource** file does not exist, the build script searches for the **License**, **Copyright**, and **Notice** files from the current directory to the root directory of the source code by default. If obtained license information will be used as the licenses of the module. +3. If the **Readme.OpenSource** file does not exist, the build script searches for the **License**, **Copyright**, and **Notice** files from the current directory to the root directory of the source code by default. The obtained license information will be used as the licenses of the module. 4. If no license is found, the default license (Apache License 2.0) will be used. Pay attention to the following: -- For third-party open-source software, such as OpenSSL and ICU, **Readme.OpenSource** must be configured in the source code directory. Check whether **Readme.OpenSource** is in the same directory as **BUILD.gn** and whether the license configured in **Readme.OpenSource** is valid. -- If the source code is not licensed under the Apache License 2.0, the corresponding license file must be provided in the source code directory or declared by **license_file** for the module. +- For third-party open-source software, such as OpenSSL and ICU, **Readme.OpenSource** must be configured in the source code directory. Check whether **Readme.OpenSource** is in the same directory as **BUILD.gn** and whether the licenses configured in **Readme.OpenSource** are valid. +- If the source code is not licensed under Apache License 2.0, the corresponding license file must be provided in the source code directory or declared in **license_file** for the module. - If the source code file added to **BUILD.gn** is not from the current directory, check whether the license in the repository where the source code file is located is the same as that in the repository of **BUILD.gn**. ## Parameters for Accelerating Local Build @@ -107,22 +107,22 @@ Pay attention to the following: The following parameters can be added to the build command to speed up the build process: - **--ccache** - - Ccache caches the output of C/C++ compilation. If the compilation input remains unchanged the next time, the compilation can be skipped and the results can be taken from the cache. + - Ccache caches the output of C/C++ compilation. If the compilation input remains unchanged the next time, the compilation can be skipped and the output can be taken from the cache. - Installing ccache: - Quick installation: Run the **sudo apt-get install ccache** command. - Download the binary file from the [official website](https://ccache.dev/download.html) and configure the ccache path to the environment variable. - - Usage: Run the **./build.sh --product-name** *Product name* **--ccache** command. + - Usage: Run the **./build.sh --product-name** *Product_name* **--ccache** command. - **--fast-rebuild** - The compilation process includes preloader -> loader -> GN -> Ninja. If the GN and product configuration files are not modified locally, adding **--fast-rebuild** will start from Ninja directly. - - Usage: Run the **./build.sh --product-name** *Product name* **--fast-rebuild** command. + - Usage: Run the **./build.sh --product-name** *Product_name* **--fast-rebuild** command. - **enable_notice_collection=false** - Adding this parameter can skip the process of collecting the module licenses of the open-source software. - - Usage: Run the **./build.sh --product-name** *Product name* **--gn-args --enable_notice_collection=false --ccache** command. + - Usage: Run the **./build.sh --product-name** *Product_name* **--gn-args --enable_notice_collection=false --ccache** command. - **--build-target** - This parameter specifies the module to compile. You can obtain the module name as follows: - Pay attention to keywords such as **group**, **ohos_shared_library**, and **ohos_executable** in **BUILD.gn**. - - Run **./build.sh --product-name** *Product name* **--build-target** *Module name* **--build-only-gn** to generate **build.ninja** and locate the related module name in the file. - - Usage: Run the **./build.sh --product-name** *Product name* **--build-target ark_js_host_linux_tools_packages** command. + - Run **./build.sh --product-name** *Product_name* **--build-target** *Module_name* **--build-only-gn** to generate **build.ninja** and locate the related module name in the file. + - Usage: Run the **./build.sh --product-name** *Product_name* **--build-target ark_js_host_linux_tools_packages** command. ## Viewing Ninja Build Information diff --git a/en/device-dev/subsystems/subsys-build-syscap.md b/en/device-dev/subsystems/subsys-build-syscap.md index f370dc6b630404e4da1fe731ecd70572f0a72654..ddb85bbfd0535cfbb7a90f78dbd3a7436a52c714 100644 --- a/en/device-dev/subsystems/subsys-build-syscap.md +++ b/en/device-dev/subsystems/subsys-build-syscap.md @@ -1,10 +1,10 @@ # Configuring System Capabilities - The SystemCapability (SysCap) module provides a set of APIs for developers to implement system capabilities. ## Configuring System Capabilities for a Component -When adding a component, you need to enable or disable specific system capabilities for it +When adding a component, you need to enable or disable specific system capabilities for it in the **bundle.json** file in the component directory. + +The following is an example: -in the **bundle.json** file in the component directory. The following is an example: ```json "component": { "name": "wifi", @@ -27,7 +27,10 @@ In this example, Wi-Fi STA, AP, and HotspotExt are enabled, and P2P and Core are ## Configuring System Capabilities for a Product When building a product, you may need to enable or disable specific system capabilities for it in **vendor/{company}/{product}/config.json**. If you do not configure system capabilities here, the system capabilities configured for the component will be used. -To configure system capabilities for a product, add the keyword **syscap** to the product **config.json** file and configure the system capabilities. The system capabilities configured for a product take precedence over the system capabilities configured for a component. If a system capability is set to **false** for the component and to **true** for the product, the system capability is enabled. The following is an example: +To configure system capabilities for a product, add the keyword **syscap** to the product **config.json** file and configure the system capabilities. The system capabilities configured for a product take precedence over the system capabilities configured for a component. If a system capability is set to **false** for the component and to **true** for the product, the system capability is enabled. + +The following is an example: + ```json { "subsystem": "communication",