1# Component
2### Configuration Rules
3
4The **bundle.json** file of a component is stored in the root directory of the component source code. The following example shows how to configure the sensor service component of the pan-sensor subsystem:
5
6```shell
7{
8    "name": "@ohos/sensor_lite",		                                 # OpenHarmony Package Manager (HPM) component name, in the "@Organization/Component name" format.
9    "description": "Sensor services",		                             # Description of the component function.
10    "version": "3.1",			                                         # Version, which must be the same as the version of OpenHarmony.
11    "license": "MIT",			                                         # Component license.
12    "publishAs": "code-segment", 		                                 # HPM package release mode. The default value is code-segment.
13    "segment": {
14        "destPath": ""
15    },					                                                 # Code restoration path (source code path) set when publishAs is code-segment.
16    "dirs": {"base/sensors/sensor_lite"},	                             # Directory structure of the HPM package. This field is mandatory and can be left empty.
17    "scripts": {},			                                             # Scripts to be executed. This field is mandatory and can be left empty.
18    "licensePath": "COPYING",
19    "readmePath": {
20        "en": "README.rst"
21    },
22    "component": { 			                                             # Component attributes.
23        "name": "sensor_lite",			                                 # Component name.
24        "subsystem": "",		                                         # Subsystem to which the component belongs.
25        "syscap": [], 				                                     # System capabilities provided by the component for applications.
26        "features": [],                                                  # List of external configurable features of the component. Generally, this parameter corresponds to sub_component in build.
27        "adapted_system_type": [],		                                 # Types of adapted systems, which can be mini, small, standard, or their combinations.
28        "rom": "92KB",                                                   # Component ROM size.
29        "ram": "~200KB",                                                 # Component RAM size.
30        "deps": {
31        "components": [                                                  # Other components on which this component depends.
32          "samgr_lite",
33          "ipc_lite"
34        ],
35        "third_party": [                                                 # Third-party open-source software on which this component depends.
36          "bounds_checking_function"
37        ],
38        "hisysevent_config": []                                          # Build entry of the HiSysEvent configuration file.
39      }
40        "build": {				                                         # Build-related configurations.
41            "sub_component": [
42                ""//base/sensors/sensor_lite/services:sensor_service"",  # Component build entry.
43            ],			                                                 # Component build entry. Configure modules here.
44            "inner_kits": [],						                     # APIs between components.
45            "test": [] 						                             # Entry for building the component's test cases.
46        }
47    }
48 }
49```
50
51> **CAUTION**
52>
53> Existing components on the LiteOS are configured in the JSON file of the corresponding subsystem in the **build/lite/components** directory. The directory is named in the **{Domain}/{Subsystem}/{Component}** format. The component directory structure is as follows:
54
55```shell
56component
57├── interfaces
58│   ├── innerkits  # APIs exposed internally among components
59│   └── kits       # APIs provided for application developers
60├── frameworks     # Framework implementation
61├── services       # Service implementation
62├── BUILD.gn       # Build script
63```
64
65You 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.
66
67> **NOTE**
68>
69> For details about how to use the HiSysEvent configuration file in component configuration, see [HiSysEvent Logging Configuration](subsys-dfx-hisysevent-logging-config.md).
70
71When adding a component, you must add the component definition to the JSON file of the corresponding subsystem. The component configured for a product must have been defined in a subsystem. Otherwise, the verification will fail.
72
73### Adding and Building a Component
74
751. Add a component.
76
77   The following use a custom component as an example to describe how to compile a library, executable file, and configuration file.
78
79   In this example, **partA** consists of **feature1**, **feature2**, and **feature3**, which represent a dynamic library, an executable file, and an etc configuration file, respectively.
80
81   Add **partA** to a subsystem, for example, **subsystem_examples** (defined in the **test/examples/** directory).
82
83   The directory structure of **partA** is as follows:
84
85   ```shell
86   test/examples/partA
87   ├── feature1
88   │   ├── BUILD.gn
89   │   ├── include
90   │   │   └── helloworld1.h
91   │   └── src
92   │       └── helloworld1.cpp
93   ├── feature2
94   │   ├── BUILD.gn
95   │   ├── include
96   │   │   └── helloworld2.h
97   │   └── src
98   │       └── helloworld2.cpp
99   └── feature3
100       ├── BUILD.gn
101       └── src
102           └── config.conf
103   ```
104
105   (a) Configure **test/examples/partA/feature1/BUILD.gn** for the dynamic library.
106
107   ```shell
108   config("helloworld_lib_config") {
109    include_dirs = [ "include" ]
110   }
111
112   ohos_shared_library("helloworld_lib") {
113     sources = [
114       "include/helloworld1.h",
115       "src/helloworld1.cpp",
116     ]
117     public_configs = [ ":helloworld_lib_config" ]
118     part_name = "partA"
119   }
120   ```
121
122   (b) Configure **test/examples/partA/feature2/BUILD.gn** for the executable file.
123
124   ```shell
125   ohos_executable("helloworld_bin") {
126     sources = [
127       "src/helloworld2.cpp"
128     ]
129     include_dirs = [ "include" ]
130     deps = [                                # Dependent modules in the component
131       "../feature1:helloworld_lib"
132     ]
133     external_deps = [ "partB:module1" ]     # (Optional) Dependent modules of another component are named in the Component name:Module name format.
134     install_enable = true                   # By default, executable programs are not installed. Set this parameter to true if an executable program needs to be installed.
135     part_name = "partA"
136   }
137   ```
138
139   (c) Configure **test/examples/partA/feature3/BUILD.gn** for the etc module.
140
141   ```shell
142   ohos_prebuilt_etc("feature3_etc") {
143     source = "src/config.conf"
144     relative_install_dir = "init"    # (Optional) Relative directory for installing the module. The default installation directory is /system/etc.
145     part_name = "partA"
146   }
147   ```
148
149   (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).
150
1512. Add the component to the product configuration file.
152
153    Add the component to **//vendor/{*product_company*}/{*product_name*}/config.json**.
154
155    The following uses **vendor/hisilicon/hispark_taurus_standard/config.json** as an example:
156
157    ```shell
158      {
159        "product_name": "hispark_taurus_standard",
160        "device_company": "hisilicon",
161        "device_build_path": "device/board/hisilicon/hispark_taurus/linux",
162        "target_cpu": "arm",
163        "type": "standard",
164        "version": "3.0",
165        "board": "hispark_taurus",
166        "inherit": [ "productdefine/common/base/standard_system.json",
167                    "productdefine/common/inherit/ipcamera.json"
168        ],
169        "enable_ramdisk": true,
170        "subsystems": [
171          {
172            "subsystem": "subsystem_examples",                              # Subsystem to which the component belongs.
173            "components": [
174              {
175                "component": "partA",                                       # Component name.
176                "features": []                                              # Configurable features of the component.
177              }
178            ]
179          },
180        ···
181      }
182    ```
183
184    The configuration file contains information about the the product name and chip vendor. **inherit** specifies the dependent, and **subsystems** specifies the components other than the common components.
185
186    For example, add "subsystem_examples:partA" to the product **config.json** file. Then, **partA** will be built and packaged into the distribution.
187
1883. Start the build.
189
190   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:
191
192   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:
193
194   ```
195   ./build.sh --product-name hispark_taurus_standard --build-target musl --ccache
196   ```
197
198   You can also build a product. For example, to build hispark_taurus_standard, run the following command:
199
200   ```shell
201   ./build.sh --product-name hispark_taurus_standard --ccache
202   ```
203
2044. Obtain the build result.
205
206    You can obtain the generated files from the **out/hispark_taurus/** directory and the image in the **out/hispark_taurus/packages/phone/images/** directory.
207