Skip to content

D
Docs

OpenHarmony / Docs
大约 1 年 前同步成功

通知 159
Star 292
Fork 28
D
Docs

体验新版 GitCode，发现更多精彩内容 >>

提交 2b8d818c 编写于 作者: W wusongqing
浏览文件
操作

Added English HPM Part 

Signed-off-by: Nwusongqing <wusongqing@huawei.com>
上级 f0336962
展开全部 隐藏空白更改
内联 并排
Showing with 833 addition and 1245 deletion
en/device-dev/bundles/Readme-EN.md
浏览文件 @ 2b8d818c
# Bundle Development
# Bundles
- [Development Specifications](bundles-standard-rules.md)
- [Development Guidelines](bundles-guide.md)
- [Bundle Development](bundles-guide-overview.md)
- [Preparations](bundles-guide-prepare.md)
- [Bundle Development](bundles-guide-develop.md)
- [HPM User Guide](bundles-demo.md)
- [Introduction](bundles-demo-hpmdescription.md)
- [Preparations](bundles-demo-environment.md)
- [Development Example](bundles-demo-devsample.md)
\ No newline at end of file
- [HPM Part Overview](hpm-part-about.md)
- [HPM Part Development](hpm-part-development.md)
- [HPM Part Reference](hpm-part-reference.md)
en/device-dev/bundles/bundles-demo-devsample.md 已删除 100644 → 0
浏览文件 @ f0336962
# Development Example<a name="EN-US_TOPIC_0000001072143838"></a>
The following uses the Hi3861 platform as an example to describe how to install and build bundles by using the hpm.
1. Run the following commands to create a directory \(its name can be customized\) and create a default project based on the dist template:
```
mkdir test3861
cd test3861
hpm init -t dist myproduct
```
If the following information is displayed, the project is created:
```
Initialization finished.
```
2. Run the following command to install the **hispark\_pegasus** distribution:
```
hpm install @ohos/hispark_pegasus
```
If the following information is displayed, the installation is successful:
```
Installed.
```
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>If you are using the Hi3516 platform, run the following command:
>```
>hpm install @ohos/hispark_taurus
>```
>If you are using the Hi3518 platform, run the following command:
>```
>hpm install @ohos/hispark_aries
>```
3. Run the following command to build and package bundles:
```
hpm dist
```
If the building is successful, the following information is displayed:
```
{{name}}: distribution building completed.
```
4. Check the result in the **./out** directory. You can burn the distribution into the corresponding development board for testing.
en/device-dev/bundles/bundles-demo-environment.md 已删除 100644 → 0
浏览文件 @ f0336962
# Configuring the Compilation Environment<a name="EN-US_TOPIC_0000001071315859"></a>
![](figure/3516dv300.png)
## Linux Server<a name="section20979554791"></a>
Prepare a 64-bit Linux server running Ubuntu 16.04 or later. \(Currently, the compilation in the Windows environment is not fully supported.\)
Configure Ubuntu to use bash as the Linux system shell, by performing the following:
```
ls -l $(which sh)
# If the file does not point to bash, modify the file using either of the provided methods.
# Method 1: Run the following command and select no:
dpkg-reconfigure dash
# Method 2: Run the following commands to delete /bin/sh and then create a new symbolic link to bash:
rm -f /bin/sh
ln -s bash /bin/sh
```
## Node.js<a name="section9954105413153"></a>
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>If the **Node.js** version of the source is outdated, run the following command before running **apt-get install**:
>```
>curl -L https://deb.nodesource.com/setup_12.x | bash
>```
You are advised to install Node.js 12.x \(including npm 6.14.4\) or a later version \(12.13.0 or later is recommended\).
```
sudo apt-get install nodejs
sudo apt-get install npm
```
Run the following commands to view **Node.js** and npm versions:
```
node --version # Check the Node.js version.
npm --version # Check the npm version.
```
## Installing hpm-cli Tool<a name="section15937194904819"></a>
Install the **hpm-cli** command line tool by using the npm \(default source: https://registry.npmjs.org/\) provided by **Node.js**.
```
npm install -g @ohos/hpm-cli
```
After **hpm-cli** is installed, run the following command to view the default hpm configurations:
```
hpm config
```
You can modify the default configurations as required. The following lists common hpm configurations:
```
registry = https://hpm.harmonyos.com # Address of the hpm registry. This is mandatory for downloading bundles.
strictSsl = true # Enable strict SSL verification as HTTPS is used for connection.
http_proxy = http://your-proxy-server:port # Configure the HTTP proxy.
https_proxy = http://your-proxy-server:port # Configure the HTTPS proxy.
```
For details about **hpm-cli** commands, see [HPM Commands](bundles-standard-rules.md).
## Python Environment<a name="section1621819180417"></a>
Run the following commands to install Python later than 3.7:
```
sudo apt-get install python3.8
sudo apt-get install python3-pip
sudo pip3 install setuptools
sudo pip3 install kconfiglib # Install kconfiglib 13.2.0 or later.
```
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>The preceding method is applicable to Hi3518 and Hi3516 platforms. For Hi3861, run the following commands to install the Python environment:
>```
>sudo apt-get install python3.8
>sudo apt-get install python3-pip
>sudo pip3 install setuptools
>sudo pip3 install kconfiglib # Install kconfiglib 13.2.0 or later.
>sudo pip3 install pycryptodome
>sudo pip3 install six --upgrade --ignore-installed six
>sudo pip3 install ecdsa
>```
If both Python2 and Python3 have been installed in the current system, run the following commands to set the default Python to Python3:
```
ll `which python`
rm /usr/bin/python
ln -s python3.8 /usr/bin/python
```
## File Packaging Tool<a name="section77617165913"></a>
Run the following commands to install the tool:
```
which mkfs.vfat # If mkfs.vfat is not found, run the following command:
sudo apt-get install dosfstools
which mcopy # If mcopy is not found, run the following command:
sudo apt-get install mtools
```
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>Both Hi3518 and Hi3516 platforms require the file packaging tool. For Hi3861, the tool is not required.
## SCons<a name="section20558439191516"></a>
1. Start a Linux server.
2. Run the following command to install the SCons installation package:
```
python3 -m pip install scons
```
3. Run the following command to check whether SCons is successfully installed. If the installation is successful, the query result shown in [Figure 1](#fig235815252492) is displayed.
```
scons -v
```
**Figure 1** Successful installation \(SCons version requirement: 3.0.4 or later\)<a name="fig235815252492"></a>
![](figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-28.png "successful-installation-(scons-version-requirement-3-0-4-or-later)-28")
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>SCons is required for the Hi3861 platform, but not for the Hi3518 or Hi3516 platform.
en/device-dev/bundles/bundles-demo-hpmdescription.md 已删除 100644 → 0
浏览文件 @ f0336962
# Introduction<a name="EN-US_TOPIC_0000001071487274"></a>
HarmonyOS package manager \(hpm\) manages and distributes OpenHarmony bundles. It offers you a tool set to obtain and customize OpenHarmony source code and perform operations such as installation, building, packaging, and upgrade.
This document describes how to use the hpm to install, build, and package OpenHarmony bundles.
en/device-dev/bundles/bundles-demo.md 已删除 100644 → 0
浏览文件 @ f0336962
# HPM User Guide<a name="EN-US_TOPIC_0000001157479397"></a>
- **[Introduction](bundles-demo-hpmdescription.md)**
- **[Configuring the Compilation Environment](bundles-demo-environment.md)**
- **[Development Example](bundles-demo-devsample.md)**
en/device-dev/bundles/bundles-guide-develop.md 已删除 100644 → 0
浏览文件 @ f0336962
# Developing Bundles<a name="EN-US_TOPIC_0000001051690861"></a>
You can use any of the following methods to develop OpenHarmony bundles:
- Create a new bundle from scratch.
- Define an existing source code project as a bundle.
## Creating a Bundle<a name="section717481119145"></a>
Generally, you can find commonly used bundles on the [HPM](https://hpm.harmonyos.com/#/en/home) website. If they cannot meet your requirements, you can develop a bundle on your own.
You can publish bundles in the HPM repository if you like, so that your peers have an option to use them.
Assume that you are planning to create a new bundle **my-bundle** in **D:/source**. Run the **hpm init** command to create the scaffold code for this bundle. For example, you can go to **D:/source** and run the following command:
```
hpm init -t default -d demo mybundle
```
The **'default'** template will be used to create a bundle named **mybundle** in the **demo** directory in **D:/source**.
```
demo
├── headers # Header file (example)
│ └── main.h
└── src # Source code (example)
│ └─ main.c
├── bundle.json # Metadata declaration file
└── LICENSE # License agreement
└── Makefile # Compilation description file (example)
└── README.md # Readme file
```
Then, complete your coding based on service requirements and generate the build script. Finally, use **git** to commit your code \(including the **bundle.json** file\) to the code hosting repository, such as gitee.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>```
>hpm init -t {templatename} -d {dir} {name}
>```
>- **-t \{templatename\}** indicates the template name.
>- **-d \{dir\}** indicates the path for storing the bundle to be created.
>- **name** indicates the name of the bundle to be created.
The hpm provides a few default templates. More templates are available on the HPM server. You can run the **hpm search -t template** command to search for a template stored on the server.
![](figure/en-us_image_0000001134127844.png)
## Defining an Existing Project as a Bundle<a name="section102861955201410"></a>
If you have a code project and need to distribute it on the HPM platform, run the following command in the current project directory, for example, **mybundle2**:
```
hpm init
```
1. Enter a bundle name \(**mybundle2** as an example\) and press **Enter**.
2. Enter the version and description. A **bundle.json** file will be generated in the current directory.
3. Open the** bundle.json** file as you like.
```
$ hpm init
Your bundle will be created in directory ~\demo\mybundle2
? bundle name mybundel2
? version 1.0.0
...
Initialization finished.
```
1. Modify other information \(such as the author, code repository, code directory, command script, and dependent bundles\) in **bundle.json**. An example is shown below:
```
{
"name": "mybundle2",
"version": "1.0.0",
"publishAs": "code-segment",
"dirs":{
".":["README.md"],
"src":["test.c"],
"header":["header/test.h" ],
"src/common":["src/common/foobar.txt"]
},
"scripts": {
"build": "make -${args}"
},
"dependencies": {
"@ohos/cjson": "^1.0.0",
"@ohos/foobar": "^1.2.0"
}
}
```
## Releasing the Bundle on the HPM Platform<a name="section1318574233211"></a>
To release a bundle on the HPM platform, you need to obtain an account and create an organization \(or join an existing organization\). For details, see the online help on the [HPM](https://hpm.harmonyos.com/#/en/home) website.
After that, generate a public key on the local PC based on your invitation code \(which can be obtained on the **My profile** page on the HPM website\), and configure the public key on the **My profile** page.
```
hpm config set loginUser {your-invitation-code}
hpm gen-keys
```
The generated file will be stored in **\~\\Users\\yourname\\.hpm\\key**. Copy the content in the public key file **publicKey\_your-account.pem** to the SSH public key on your **My profile** page.
After finishing the preceding operations, you then have the permission to release bundles in your organization.
In the directory where the bundle is located, run the following command to package and release the bundle:
```
hpm publish
```
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>- To avoid bundle name conflicts, name a released bundle in the format of **@org\_name/bundle\_name**.
>- Your account must also be a member of **org\_name** so that you can release or update bundles in the organization.
>- The released bundles take effect only after security and content reviews.
## Referencing a Bundle<a name="section19311124115315"></a>
Generally, when developing a project, you may need to reference other bundles in order to accelerate development of specific functions. Installing dependencies could be a good way.
Go to the HPM website, search for bundles that meet your service requirements by keywords, and then introduce the bundles to your project.
Run the following command in your bundle project. Make sure that the project directory contains the **bundle.json** file.
```
$ hpm install @scope/the_bundle
```
The referenced bundle will be installed under **ohos\_bundle** in the directory where your project is located. The directory structure is as follows:
```
project
├── ohos_bundle
│ └── scope
│ └─ the_bundle # <--- Referenced bundle
└── src
│ └─ main.c
├── bundle.json # Metadata declaration file
└── LICENSE
└── Makefile
└── README.md
```
Open the **bundle.json** file. You will see that the bundle has been introduced to the dependencies of your project.
```
{
"dependencies": {
"@scope/the_bundle": "^1.0.0"
}
}
```
You can also edit the dependencies of multiple bundles in this file at a time.
```
{
"dependencies": {
"@scope/the_bundle1": "^1.0.0",
"@scope/the_bundle2": "^2.0.0",
"@scope/the_bundle3": "^3.0.0",
"@scope/the_bundle4": "^1.1.0"
}
}
```
Run the **hpm install** command again to download and install all bundles that have not been installed.
## Installing a Bundle Globally<a name="section165131927192120"></a>
If the referenced bundle is one shared by multiple projects, for example, the compiler toolchain, you can install it globally.
Run the following command in your bundle project. Make sure that the project directory contains the **bundle.json** file.
```
$ hpm install -g @scope/the_tool
```
The referenced bundle will be installed in the directory specified by the **globalRepo** parameter of the **hpm config** command.
```
~\.hpm\global
│ └── scope
│ └─ the_tool # <--- Referenced bundle
```
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>- For a bundle installed in a project, you can reference it using the environment variable **DEP\_SCOPE\_bundle\_name** when running the hpm compilation command.
>For example, after you run **hpm i @opensource/gn** to install a bundle, you can edit the build script in the **bundle.json** file as follows:
>```
>"scripts": {
> "build": "${DEP_OPENSOURCE_gn}/gn --version"
> },
>```
>Then, you can run the **hpm build** command to call GN functions.
>- For a globally installed bundle, you can directly call the bundle using an environment variable or reference the bundle using the **$\{key\}/tool\_name** parameter when running the **hpm config set key value** command. For example:
>```
>hpm i -g @ohos/opensource/gn
>hpm config BUILD_SYS_GN ~/.hpm/global/ohos_bundles/opensource/gn
>```
>You can edit the build script in the **bundle.json** file as follows:
>```
>"scripts": {
> "build": "${BUILD_SYS_GN}/gn --version"
> },
>```
>Then, you can run the **hpm build** command to call GN functions.
## Compiling a Bundle<a name="section136732148541"></a>
If the bundle code can be independently compiled once you finish coding, you can configure build tools and scripts to generate binary files.
The hpm supports command integration so that you can select any build tool \(such as **make**, **gcc**, and **gn**\) suitable for your project. You only need to define the **build** command in the **scripts** in the **bundle.json** file of your project, and then you run the hpm command **build** to perform building.
## Defining the Build Script<a name="section10274147111610"></a>
This section uses how to build an executable file **helloworld** in the **app** directory as an example.
```
app
├── BUILD.gn
├── include
│ └── helloworld.h
└── src
└── helloworld.c
```
Create a **BUILD.gn** file in the same directory as **helloworld.c**.
```
touch BUILD.gn
vim BUILD.gn
```
The following is an example of **BUILD.gn** for your reference:
```
executable("hello_world") {
sources = [
"src/helloworld.c"
]
include_dirs = [
"include"
]
}
```
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>- **executable** is a built-in template of **gn**. You can run the **gn help executable** command to view how to use this template.
>- **sources** represents the source code path, and **include\_dirs** represents the header file path.
## Executing the Build Script<a name="section879301916172"></a>
Run the following command:
```
hpm build
```
After all building operations are complete, the message "build succeed" is displayed. You need to check the building result.
![](figure/en-us_image_0000001051770876.png)
## Defining a Distribution<a name="section413216495619"></a>
This process states the dependent bundles and how to compile and link the bundles to generate image files.
This section uses the hb compilation framework as an example.
## Defining Scripts<a name="section11503171219190"></a>
An example definition in the **bundle.json** file is as follows:
\{
"name": "@your/dist\_name",
"version": "2.2.0",
"publishAs": "distribution",
"description": "describe it",
"scripts": \{
"config\_hb": "hb set -root $DEP\_BUNDLE\_BASE",
"dist": "PATH=/root/.local/bin:$\{DEP\_OHOS\_gn\}:$\{DEP\_OHOS\_ninja\}/ninja:$\{DEP\_OHOS\_llvm\}/llvm/bin:$\{DEP\_OHOS\_hc\_gen\}/hc-gen:$\{PATH\} && ./scripts/dist.sh"
\},
"envs": \{
"debug": false
\},
"dirs": \{
"scripts": "scripts/\*"
\},
"dependencies": \{
"@ohos/build\_lite": "2.2.0",
"@ohos/gn": "1.1.1",
"@ohos/llvm": "1.1.1",
"@ohos/hc\_gen": "1.1.0",
"@ohos/ninja": "1.1.0",
...
\},
"ohos": \{
"os": "2.2-Beta",
"board": "hi3516",
"kernel": "liteos-a"
\},
"keywords": \[ "hispark", "hi3516" \],
"repository": "https://gitee.com/openharmony/your-project",
"license": "Apache V2"
\}
## Building a Distribution<a name="section4694125521912"></a>
Run the following command in the root directory of the current distribution:
```
hpm dist
```
The **hpm-cli** tool automatically starts compilation. After the compilation is complete, an image file will be generated, as shown below:
```
out
|-xxdist.img
|-xx.file
```
Burning
The build result of the distribution can be burnt into devices, for example, by using the **hiburn** tool. You need to configure burning parameters in the **bundle.json** file of the distribution.
```
"scripts": {
"flash": "{$DEP_HIBURN}/hiburn"
},
```
Set the path of the **hiburn** tool and set burning parameters. For details, see the **hiburn** tool guide.
```
hpm config set DEP_HIBURN {hiburn_path}
hpm run flash
```
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>The preceding example describes only how to define the **bundle.json** file. The burning tool is subject to the actual development board.
en/device-dev/bundles/bundles-guide-overview.md 已删除 100644 → 0
浏览文件 @ f0336962
# Overview<a name="EN-US_TOPIC_0000001051452100"></a>
This section describes the bundle-specific concepts in HarmonyOS. It uses an example to step you through how to create, develop, build, release, and install a bundle using the **hpm-cli** tool.
## Bundle<a name="section196713235514"></a>
A bundle is a term used in HarmonyOS to indicate a distribution. A bundle is equivalent to a package and it usually contains the following contents:
- Distributed binary file \(binary type\)
- Distributed source code file \(source code/code snippet type\)
- Build script \(distribution type\)
- Bundle description files:
- **bundle.json**: metadata declaration \(name, version, dependency, etc.\)
- **LICENSE**: license agreement
- **README.md**: readme file
- **CHANGELOG.md**: change log \(optional\)
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>Bundles can be classified into the following types: binary, source code, code snippet, template, plug-in, distribution, and so on. A bundle can depend on other bundles. The dependency relationship can be represented by a directed acyclic graph \(DAG\).
After you release a bundle on the [HPM](https://hpm.harmonyos.com/#/en/home) platform, other developers can download, install, and use the bundle through the HarmonyOS Package Manager \(hpm\).
A bundle must be uniquely named in the format **@scope/name** in the namespace. Independent evolution is supported for each bundle.
## Distribution<a name="section155387501033"></a>
A distribution is a complete HarmonyOS release that integrates various bundles, including drivers, kernels, frameworks, and applications. A distribution can also be distributed on the [HPM](https://hpm.harmonyos.com/#/en/home) platform through bundles.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>The metadata of a distribution describes only the dependent bundles and build script compilation methods. It does not cover binary images of the distribution. When downloading a distribution, you also need to download the dependent bundles. You can obtain the system image file for burning only after finishing installation and compilation.
>A distribution is inheritable. Specifically, you can add bundles to or delete bundles from an existing distribution to create your own distribution.
**Figure 1** Relationship between bundles and a distribution<a name="fig85033524124"></a>
![](figure/bundle-distribution.png)
en/device-dev/bundles/bundles-guide-prepare.md 已删除 100644 → 0
浏览文件 @ f0336962
# Installing hpm-cli Tool<a name="EN-US_TOPIC_0000001051770836"></a>
To develop a bundle, you first need to install the HarmonyOS Package Manager \(hpm\), a cross-platform command line tool developed based on Node.js. To run the hpm, you need to install Node.js, and then install the hpm using the Node Package Manager \(npm\).
## Installing Node.js and hpm<a name="section106591616205311"></a>
1. Install **Node.js**.
Download **Node.js** from its official website and install it on your local PC.
You are advised to install [Node.js](https://nodejs.org/) 12.x \(including npm 6.14.4\) or a later version \(12.13.0 or later is recommended\).
2. Install the **hpm-cli** tool using **npm** delivered with **Node.js**. Run the following command:
```
npm install -g @ohos/hpm-cli
```
3. Run the following command to check whether the installation is successful. If an hpm version is displayed, the installation is successful.
```
hpm -V or hpm --version
```
4. \(Optional\) Run the following command to upgrade the hpm version if needed:
```
npm update -g @ohos/hpm-cli
```
## \(Optional\) Configuring hpm<a name="section71821165412"></a>
After the **hpm-cli** tool is installed, run the following command to view the hpm configuration if you need to modify the configuration information, such as proxy and shell:
```
hpm config
```
Default hpm configurations are displayed upon successful command execution. You can modify the default configurations as required. The following lists common hpm configurations:
```
registry = https://hpm.harmonyos.com
### login Settings
# loginUser = invitation_code
#### Path Settings
shellPath = C:\WINDOWS\System32\cmd.exe
# shellPath = C:\Program Files\Git\bin\sh.exe
# globalRepo = C:\Users\username\.hpm\global
#### Network Settings
# no_proxy = *.server.com
# http_proxy = http://user:pwd@proxy_server:port
# https_proxy = http://user:pwd@proxy_server:port
# strictSsl = true
#### Other Settings
# privateSupport = true|false
# ignoreBundles = @ohos/llvm,@ohos/gn,
# OSPlatform = Auto|linux|darwin|win32
```
For details about **hpm-cli** commands, see [HPM Commands](bundles-guide-overview.md).
## Downloading OpenHarmony Code<a name="section102338221707"></a>
For details, see [Source Code Acquisition](../get-code/sourcecode-acquire.md).
en/device-dev/bundles/bundles-guide.md 已删除 100644 → 0
浏览文件 @ f0336962
# HPM Bundle Development Guidelines<a name="EN-US_TOPIC_0000001157319417"></a>
- **[Overview](bundles-guide-overview.md)**
- **[Installing hpm-cli Tool](bundles-guide-prepare.md)**
- **[Developing Bundles](bundles-guide-develop.md)**
en/device-dev/bundles/bundles.md 已删除 100644 → 0
浏览文件 @ f0336962
# Bundle Development<a name="EN-US_TOPIC_0000001111039520"></a>
- **[Bundle Development Specifications](bundles-standard-rules.md)**
- **[Development Guidelines](bundles-guide.md)**
- **[HPM User Guide](bundles-demo.md)**
en/device-dev/bundles/hpm-part-about.md 0 → 100644
浏览文件 @ 2b8d818c
# HPM Part Overview
This section describes the basic concepts related to HPM Part in OpenHarmony.
## Introduction to HPM Part
### HPM Part Category
An HPM Part is used as a distribution unit in OpenHarmony. There are two types of HPM Parts:
- **Part/Module-level HPM Part**: used to achieve module or part reusability. The distributed content can be source code or binary files. Generally, such an HPM Part corresponds to a code repository and is a release of the code repository.
- **Distribution-level HPM Part**: used to describe an OS distribution. It consists of a list of dependent parts and scripts for building the distribution. The distribution contains various components (such as the driver, kernel, framework, and applications) of a complete OS. The image generated after the build can be used for burning.
### HPM Part Composition
An HPM Part consists of two types of files: description file and content file.
The table below lists the description files.
**Table 1** Description files
| File Name| Description | Mandatory |
| -------- | -------- | -------- |
| bundle.json | Metadata declaration file| Yes|
| README.md | Readme file| Yes|
| LICENSE | License file| Yes|
| CHANGEME.md | Change log file| No|
The content files can be any of the following:
- Binary file of the distributed part
- Source code file of the distributed part
- Build script file
**Figure 1** Relationship between the part/module-level HPM Part and distribution-level HPM Part
![en-us_image_0000001195369804](figures/en-us_image_0000001195369804.png)
## Introduction to HPM
OpenHarmony Package Manager (HPM) is an open collaboration platform that connects consumers and providers. HPM Parts are objects managed by HPM.
Through this platform, the provider can publish HPM Parts and the consumer can download and use HPM Parts.
- The provider declares the attributes of an HPM Part and publishes it to the platform.
- The consumer declares the dependencies in the HPM Part of the specified version to obtain the required resources.
The HPM platform matches the requirements of the provider and consumer.
**Figure 2** HPM functions
![en-us_image_0000001240409717](figures/en-us_image_0000001240409717.png)
**HPM consists of the following:**
- **hpm-cli: a cross-platform command line tool released in [@ohos/hpm-cli](https://www.npmjs.com/package/@ohos/hpm-cli)**
The hpm-cli tool offers a series of commands for creating, building, installing, packing, running, and publishing HPM Parts. You can use these commands to manage the lifecycle of the HPM Parts.
- **[DevEco Marketplace](https://repo.harmonyos.com): a resource repository on the server**
On [DevEco Marketplace](https://repo.harmonyos.com), you can register, store, and search for HPM Parts by category. Each HPM Part has a page providing access to its readme file, dependencies, historical versions, change history, license, download volume, and source code repository address. You can publish HPM Parts to this resource repository.
en/device-dev/bundles/hpm-part-development.md 0 → 100644
浏览文件 @ 2b8d818c
# HPM Part Development
## HPM Part Development Overview
You can search for common development resources on [DevEco Marketplace](https://repo.harmonyos.com) and import required resources to your projects through dependencies. If you cannot find the desired resources there, develop the resources on your own and publish them in the form of an HPM Part. To develop HPM Parts, install the hpm-cli tool first.
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
> You are advised to perform the following operations on Ubuntu 18.04 or later.
## Installing hpm-cli
The hpm-cli tool is developed based on Node.js. Therefore, you must install Node.js and then use npm to install hpm-cli.
### Installing Node.js and hpm-cli
1. Install Node.js.
Download Node.js from its official website and install it on your local PC.
You are advised to install the latest LTS version (not earlier than 12.x) of [Node.js](https://nodejs.org/).
2. Install the hpm-cli tool using **npm** delivered with **Node.js**. Run the following command:
```
npm install -g @ohos/hpm-cli
```
3. Run the following command to check whether the installation is successful. If a hpm version is displayed, the installation is successful.
```
hpm -V or hpm --version
```
4. (Optional) Run the following command to update the hpm version if needed:
```
npm update -g @ohos/hpm-cli
```
### (Optional) Configuring hpm-cli
After hpm-cli is installed, run the following command to view the hpm configuration:
```
hpm config
```
The default hpm configuration is displayed upon successful command execution. You can modify the default configuration as required. The following lists the common hpm configuration:
```
registry = https://hpm.harmonyos.com
### login Settings
# loginUser = invitation_code
#### Path Settings
shellPath = C:\WINDOWS\System32\cmd.exe
# shellPath = C:\Program Files\Git\bin\sh.exe
# globalRepo = C:\Users\username\.hpm\global
#### Network Settings
# no_proxy = *.server.com
# http_proxy = http://user:pwd@proxy_server:port
# https_proxy = http://user:pwd@proxy_server:port
# strictSsl = true
#### Other Settings
# privateSupport = true|false
# ignoreBundles = @ohos/llvm,@ohos/gn,
# OSPlatform = Auto|linux|darwin|win32
```
## Creating an HPM Part
You can create an HPM Part by using a template or define an existing project as an HPM Part.
### Creating an HPM Part Using a Template
1. Run the following command to create a directory:
```
hpm init -t default mybundle
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
> -In the preceding command, **default** indicates that the **default** template is used. You can use another template such as **simple** or **dist**.
The generated directory structure is as follows:
```
/
├── headers # Header file (example)
│ └── main.h
└── src # Source code (example)
│ └─ main.c
├── bundle.json # Metadata declaration file
└── LICENSE # License
└── Makefile # Build description file (example)
└── README.md # Readme file
```
2. Write the code and build script of the HPM Part.
```
hpm init -t {templatename} -d {dir} {name}
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
> - -**t {templatename}** indicates the template name.
>
> - -**d {dir}** indicates the path for storing the HPM Part to be created.
>
> - **name** indicates the name of the HPM Part to be created.
The hpm-cli tool provides a few default templates. More templates are available on [DevEco Marketplace](https://repo.harmonyos.com). You can run the **hpm search -t template** command to search for a template stored on [DevEco Marketplace](https://repo.harmonyos.com).
![zh-cn_image_0000001217486680](figures/zh-cn_image_0000001217486680.png)
### Defining an Existing Project as an HPM Part
If you have a code project and need to distribute it on the HPM platform, run the following command in the project directory, for example, **mybundle2**:
```
hpm init
```
1. Enter an HPM Part name (**mybundle2** for example) and press **Enter**.
2. Enter the version and description. A **bundle.json** file will be generated in the current directory.
3. Open the **bundle.json** file.
```
$ hpm init
Your bundle will be created in directory ~\demo\mybundle2
? bundle name mybundle2
? version 1.0.0
...
Initialization finished.
```
4. Modify other information (such as the author, code repository, code directories, scripts, and dependencies) in **bundle.json**. An example is shown below:
```
{
"name": "mybundle2",
"version": "1.0.0",
"publishAs": "code-segment",
"dirs":{
".":["README.md"],
"src":["test.c"],
"header":["header/test.h" ],
"src/common":["src/common/foobar.txt"]
},
"scripts": {
"build": "make -${args}"
},
"dependencies": {
"@ohos/cjson": "^1.0.0",
"@ohos/foobar": "^1.2.0"
}
}
```
## Defining a Distribution
In the distribution metadata file, define the dependent HPM Parts and how to build and link them to generate image files.
The following uses the **bundle.json** file as an example. In this example, the **dist** command uses the **hb** framework.
```
{
"name": "@your/dist_name",
"version": "2.2.0",
"publishAs": "distribution",
"description": "describe it",
"scripts": {
"config_hb": "hb set -root $DEP_BUNDLE_BASE",
"dist": "PATH=/root/.local/bin:${DEP_OHOS_gn}:${DEP_OHOS_ninja}/ninja:${DEP_OHOS_llvm}/llvm/bin:${DEP_OHOS_hc_gen}/hc-gen:${PATH} && ./scripts/dist.sh"
},
"envs": {
"debug": false
},
"dirs": {
"scripts": "scripts/*"
},
"dependencies": {
"@ohos/build_lite": "2.2.0",
"@ohos/gn": "1.1.1",
"@ohos/llvm": "1.1.1",
"@ohos/hc_gen": "1.1.0",
"@ohos/ninja": "1.1.0",
......
},
"ohos": {
"os": "2.2-Beta",
"board": "hi3516",
"kernel": "liteos-a"
},
"keywords": [ "hispark", "hi3516" ],
"repository": "https://gitee.com/openharmony/your-project",
"license": "Apache V2"
}
```
## Building an HPM Part
If the code of an HPM Part can be independently built, you can configure the build tool and scripts to generate binary files.
The hpm-cli tool supports command integration so that you can select any build tool (such as make, gcc, and gn) suitable for your project. You only need to define the **build** command in **scripts** in the **bundle.json** file of your project, and then run the **hpm build** command to start the build.
### Defining the Build Script
This section describes how to build an executable file named **helloworld** in the **app** directory.
```
app
├── BUILD.gn
├── include
│ └── helloworld.h
└── src
└── helloworld.c
```
Create a **BUILD.gn** file in the same directory as **helloworld.c**.
```
touch BUILD.gn
vim BUILD.gn
```
The following is an example of **BUILD.gn**:
```
executable("hello_world") {
sources = [
"src/helloworld.c"
]
include_dirs = [
"include"
]
}
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
> - **executable** is a built-in template of gn. You can run the **gn help executable** command to view how to use this template.
>
> - **sources** represents the source code path, and **include_dirs** represents the header file path.
### Executing the Build Script
Run the following command to start the build:
```
hpm build
```
After all build operations are complete, the message "build succeed" is displayed. You need to check the build result.
![zh-cn_image_0000001262166533](figures/zh-cn_image_0000001262166533.png)
### Building an Image
Run the following command in the root directory of the current distribution:
```
hpm dist
```
The hpm-cli tool automatically starts the build. After the build is complete, an image file will be generated, as shown below:
```
out
|-xxdist.img
|-xx.file
```
## Publishing an HPM Part
To publish an HPM Part, you must obtain an account and create an organization (or join an existing organization). For details, see the online help on [DevEco Marketplace](https://repo.harmonyos.com).
After that, generate a public key on the local PC based on your invitation code (which can be obtained on the **My profile** page on [DevEco Marketplace](https://repo.harmonyos.com)), and configure the public key on the **My profile** page.
```
hpm config set loginUser {your-invitation-code}
hpm gen-keys
```
The generated file will be stored in **~\Users\yourname\.hpm\key**. Copy the content in the public key file **publicKey_your-account.pem** to the SSH public key on your **My profile** page.
Now you have the permission to publish HPM Parts in your organization.
In the directory where the HPM Part is located, run the following command to pack and publish the HPM Part:
```
hpm publish
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
> - To avoid HPM Part name conflicts, name an HPM Part in the format of **\@org_name/bundle_name**.
>
> - Your account must also be a member of **org_name** so that you can publish or update HPM Parts in the organization.
>
> - The published HPM Parts take effect only after security and content reviews.
## Using an HPM Part
### Using a Part
When developing a project, you usually need to reference other HPM Parts to accelerate development of specific functions. Installing dependencies could be a good way.
Visit [DevEco Marketplace](https://repo.harmonyos.com), search for HPM Parts that meet your service requirements by keywords, and then introduce them to your project. The typical operation procedure is as follows:
1. Run the **hpm init** command to create a bundle description file named **bundle.json**, which contains dependencies and other metadata such as the name and version.
2. Run the **hpm install <name>** command to install the dependency. The dependency will be written into the **dependencies** field in **bundle.json**.
3. Reference the header file in the code to implement the function.
4. Run the **hpm build** command to perform build and output the build result.
Run the following command in your project. Make sure that the project directory contains the **bundle.json** file.
```
$ hpm install @scope/the_bundle
```
The referenced HPM Part will be installed under **ohos_bundle** in the directory where your project is located. The directory structure is as follows:
```
project
├── ohos_bundle
│ └── scope
│ └─ the_bundle # <--- Referenced HPM Part
└── src
│ └─ main.c
├── bundle.json # Metadata declaration file
└── LICENSE
└── Makefile
└── README.md
```
Open the **bundle.json** file. You will see that the HPM Part has been introduced to the dependencies of your project.
```
{
"dependencies": {
"@scope/the_bundle": "^1.0.0"
}
}
```
You can edit the dependencies of multiple HPM Parts in this file.
```
{
"dependencies": {
"@scope/the_bundle1": "^1.0.0",
"@scope/the_bundle2": "^2.0.0",
"@scope/the_bundle3": "^3.0.0",
"@scope/the_bundle4": "^1.1.0"
}
}
```
Run the **hpm install** command again to download and install all HPM Parts that have not been installed.
### Installing Global HPM Parts
If the referenced HPM Part is shared by multiple projects, for example, the compiler toolchain, you can install it globally.
Run the following command in your project. Make sure that the project directory contains the **bundle.json** file.
```
$ hpm install -g @scope/the_tool
```
The referenced HPM Part will be installed in the directory specified by the **globalRepo** parameter of the **hpm config** command.
```
~\.hpm\global\ohos_bundles
│ └── scope
│ └─ the_tool # <--- Referenced HPM Part
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
> - For an HPM Part installed in a project, you can reference it using the environment variable **DEP_SCOPE_bundle_name** when running the hpm build command.
> For example, after you run **hpm i \@opensource/gn** to install an HPM Part, edit the build script in the **bundle.json** file as follows:
>
> ```
> "scripts": {
> "build": "${DEP_OPENSOURCE_gn}/gn --version"
> },
> ```
>
> Then, you can run the **hpm build** command to call gn functions.
>
> - For a globally installed HPM Part, you can directly call the HPM Part using an environment variable or reference the HPM Part using the **${key}/tool_name** parameter in the **hpm config set key value** command. Example:
>
> ```
> hpm i -g @ohos/opensource/gn
> hpm config BUILD_SYS_GN ~/.hpm/global/ohos_bundles/opensource/gn
> ```
>
> You can edit the build script in the **bundle.json** file as follows:
>
> ```
> "scripts": {
> "build": "${BUILD_SYS_GN}/gn --version"
> },
> ```
>
> Then, you can run the **hpm build** command to call gn functions.
en/device-dev/bundles/hpm-part-reference.md 0 → 100644
浏览文件 @ 2b8d818c
# HPM Part Reference
This section describes the HPM Part division rules, HPM Part types, HPM Part composition, metadata fields, and common CLI commands.
### HPM Part Division Rules
In principle, HPM Parts should be grouped at a fine-grained granularity to achieve maximum reuse. The following factors are taken into account:
- Independence: HPM Parts provide relatively independent features and can be independently built. Each HPM Part is capable of providing its own APIs and services for external systems.
- Coupling: If an HPM Part must depend on another one to provide services, they can be coupled to one HPM Part.
- Correlation: If a group of HPM Parts jointly implement a feature, and if other HPM Parts never depend on them, the group of HPM Parts can be combined into one HPM Part.
### HPM Part Type
HPM Parts are introduced for reuse purposes.
**Table 1** HPM Part types
| Item| Description|
| -------- | -------- |
| source | Distributed in the form of source code. It is depended by the target project, and can be compiled independently.|
| binary | Distributed in binary mode. It does not contain source code, such as build tools.|
| code-segment | Distributed in the form of code snippets and cannot be compiled independently. After the installation, it is restored to the specified directory and participates in other code build in the target project.|
| distribution | Distributed as a distribution and dependent on other HPM Parts. It does not contain source code (except build scripts). The build output is system images.|
| template | Distributed as a template and used by the **hpm init** command to create a template.|
| plugin | Distributed as a plugin of hpm-cli to provide more functions.|
### HPM Part Composition
An HPM Part contains the following:
- **src** directory for storing code files or code library of the HPM Part.
- **ohos_bundles** folder for storing dependent HPM Parts. The folder is automatically generated during HPM Part installation and does not need to be committed to the code library.
- **README.md** file for describing the HPM Part.
- **bundle.json** file for declaring metadata of the HPM Part.
- LICENSE file for open-source code.
```
my-bundle
|_ohos_bundles
|_headers
|_src
|_bundle.json
|_README.md
|_LICENSE
```
### src Source Code
HPM Part code files are the same as those in a common code directory. The only difference lies in the open APIs (declared in header files) provided by HPM Parts, which will be referenced by other HPM Parts and must be declared in **dirs** of **bundle.json**.
### README File
To help consumers find your HPM Part on [DevEco Marketplace](https://repo.harmonyos.com) and use it more conveniently, include a **README.md** file in the root directory of the HPM Part.
**README.md** is a file written using the markdown syntax.
The **README.md** file may include instructions on how to install, configure, and use the sample code in the HPM Part, as well as any other information helpful to the consumers.
The Readme file will be displayed on the homepage of the HPM Part on [DevEco Marketplace](https://repo.harmonyos.com).
## bundle.json File
The **bundle.json** file describes the metadata of an HPM Part. Each HPM Part has its own **bundle.json** file. The file content is as follows:
```
{
"name": "@myorg/demo-bundle",
"version": "1.0.0",
"license": "MIT",
"description": "bundle description",
"keywords": ["hos"],
"tags": ["applications", "drivers"],
"author": {"name":"","email":"","url":""},
"contributors":[{"name":"","email":"","url":""},{"name":"","email":"","url":""}],
"homepage": "http://www.foo.bar.com",
"repository": "https://git@gitee.com:foo/bar.git",
"private": false,
"publishAs": "code-segment",
"segment":{
"destPath":"/the/dest/path"
},
"dirs": {
"src": ["src/**/*.c"],
"headers": ["headers/**/*.h"],
"bin": ["bin/**/*.o"]
},
"scripts": {
"build": "make"
},
"envs": {},
"ohos": {
"os": "2.0.0",
"board": "hi3516",
"kernel": "liteos-a"
},
"rom": "10240",
"ram": "1024",
"dependencies": {
"@myorg/net":"1.0.0"
}
}
```
Each **bundle.json** file has the following fields:
- **name**: an HPM Part name, which starts with the at sign (@) and is separated with the organization name by the slash (/), for example, **\@myorg/mybundle**.
- **version**: version of the HPM Part, for example, 1.0.0. The version must comply with the Semantic Versioning Specification (SemVer) standards.
- **description**: a brief description of the HPM Part.
- **dependencies**: dependent HPM Parts.
- **envs**: parameters required for building the HPM Part, including global parameters and dependency parameters.
- **scripts**: commands executable to the HPM Part, such as commands for compiling, building, testing, and burning.
- **publishAs**: HPM Part publishing type, which can be **source**, **binary**, **distribution**, or **code-segment**.
- **segment**: destination path of the code-segment HPM Part, that is, the destination path of the files contained in the HPM Part after the HPM Part is installed.
- **dirs**: directory structure (such as the header file) generated for publishing.
- **ram** and **rom**: statistical information about the estimated read-only memory (ROM) and random access memory (RAM) usage.
- **ohos**: mappings among OpenHarmony versions, development boards, and kernels, separated by commas (,).
- Extended information: author, home page, code repository, license, tags, and keywords.
- For a distribution-level HPM Part, you can define the inheritance relationship and use the **base** field to describe the basic distribution and version that are inherited from.
- **private**: indicates whether an HPM Part is private. A private HPM Part cannot be found by other organizations. The default value is **false**.
## HPM CLI Commands
You can use the hpm-cli tool to manage the lifecycle of an HPM Part. The following table describes available hpm-cli commands. You can run the **hpm -h** command to get the command details.
**Table 2** Commands available on hpm-cli
| Command Type| Command Line| Description|
| -------- | -------- | -------- |
| Querying version information| **hpm -V** or **hpm --version**| Displays the version of the hpm-cli tool.|
| Querying help information| **hpm -h** or **hpm --version**| Displays the command list and help information.|
| hpm&nbsp;-h | Displays command help information.|
| Creating a project| hpm&nbsp;init&nbsp;bundle | Creates an HPM Part project.|
| hpm&nbsp;init&nbsp;-t&nbsp;template | Creates a scaffolding project from a template.|
| Installing HPM Parts| **hpm install** or **hpm i**| Installs dependent HPM Parts in the bundle.json file.|
| hpm&nbsp;install&nbsp;bundle\@version | Installs HPM Parts of a specified version.|
| Uninstalling HPM Parts| hpm&nbsp;uninstall&nbsp;bundle | Uninstalls dependent HPM Parts.|
| **hpm remove** or **hpm rm bundlename**| Uninstalls dependent HPM Parts.|
| Viewing information| **hpm list** or **hpm ls**| Displays the dependency tree of the HPM part.|
| hpm&nbsp;dependencies | Generates the dependency relationship data of the HPM Part. (This command is also integrated in the **hpm ui** command. After you run the hpm ui command, a hpm UI is displayed with the dependencies.)|
| Searching for HPM Parts| hpm&nbsp;search&nbsp;name | Searches for HPM Parts. **--json** is used to specify the search result in JSON format, and **-type** is used to set the target type, which can be **part**, **distribution**, or **code-segment**.|
| Setting HPM configuration items| hpm&nbsp;config&nbsp;set&nbsp;key&nbsp;value | Sets configuration items, such as the server address and network proxy.|
| hpm&nbsp;config&nbsp;delete&nbsp;key | Deletes configurations.|
| Updating HPM Part versions| hpm&nbsp;update | Updates the versions of dependent HPM Parts.|
| hpm&nbsp;check-update | Checks whether version updates are available to dependent HPM Parts.|
| Building| hpm&nbsp;build | Builds an HPM Part.|
| hpm&nbsp;dist | Builds a distribution. The build depends on the **dist** script in **scripts** of **bundle.json**.|
| Packing | hpm&nbsp;pack | Packs dependencies of local HPM Parts.|
| Burning| hpm&nbsp;run&nbsp;flash | Burns the firmware. The firmware burning depends on the **flash** script in **scripts** of **bundle.json**.|
| Publishing| hpm&nbsp;publish | Publishes an HPM Part, which must be unique in the repository and has a unique version. (An account is required for login.)|
| Running of extended commands| hpm&nbsp;run | Runs the commands in **scripts** defined in **bundle.json**. Multiple commands can be executed at a time by using **&&**.|
| Decompressing| hpm&nbsp;extract | Decompresses files in zip, tar, tgz, or .tar.gz format.|
| Starting UI| hpm&nbsp;ui | Starts the hpm UI locally. You can use the **-p** parameter to specify a port. On the Windows platform, the default browser is used to open the HPM UI.|
| Changing language| hpm&nbsp;lang | Alternates between Chinese and English on the CLI and UI.|
| Converting to HPM format| hpm&nbsp;x2h | Converts a Maven or npm package to an HPM Part and publishes it on the HPM platform.|
| Code segment restoration or cleanup| hpm&nbsp;code&nbsp;clean\|restore | Clears or restores the dependent code segment, which is equivalent to copying or deleting the code segment based on **segment.destPath**.|
| Generating a key| hpm&nbsp;gen-keys | Generates a public-private key pair and configures the public key on [DevEco Marketplace](https://repo.harmonyos.com), which enables password-free hpm-cli login for HPM Part publishing.|
| Generation of the third-party open source notice| hpm&nbsp;gen-notice | Generates a file providing the notice on third-party open source by combining the description of each HPM Part.|
## About Dependency
HPM Part dependencies are classified as mandatory and optional dependencies.
- Mandatory dependency: If HPM Part A must depend on HPM Part B to implement a feature (the APIs or services specific to HPM Part B must be called), HPM Part B is a mandatory dependency of HPM Part A.
- Optional dependency: If either HPM Part C or D is required for HPM Part A to implement a feature, and if HPM Parts C and D are interchangeable, HPM Parts C and D are optional dependencies of HPM Part A.
```
"dependencies": {
"@myorg/core":"1.0.0",
"?@myorg/plugin1":"1.0.0",
"?@myorg/plugin2":"1.1.0"
}
```
HPM Part dependencies can also be classified as compilation and development dependencies.
- Compilation dependency: dependency required for runtime.
- Development dependency: dependency required in non-runtime scenarios, such as static check, build, packing, test, and formatting tools.
```
"dependencies": {
"@myorg/core":"1.0.0"
},
"devDependencies": {
"@myorg/tool":"1.0.0"
}
```
Tags can be defined to group dependent HPM Parts. You can obtain the path of a group of dependent HPM Parts based on their tag. A tag starts with a number sign (#) and is defined as follows:
```
{
"dependencies": {
"#tool": {
"first_bundle": "1.0.0",
"second_bundle": "1.0.0"
},
"#drivers": {
"xx_bundle": "1.0.0",
"yy_bundle": "1.0.0"
}
}
}
```
HPM Part dependencies (including indirect dependencies) can be displayed by running the **hpm list** command or on the hpm UI, which is started by running the **hpm ui** command.
```
$ hpm list
+--demo@1.0.0
| +--@huawei/media@1.0.2
| +--@demo/sport_hi3518ev300_liteos_a@1.0.0
| | +--@demo/app@4.0.1
| | | +--@demo/build@4.0.1
| | | +--@demo/arm_harmonyeabi_gcc@4.0.0
| | +--@demo/liteos_a@4.0.0
| | | +--@demo/third_party_fatfs@4.0.0
| | | +--@demo/arm_harmonyeabi_gcc@4.0.0
| | +--@demo/init@4.0.0
| | +--@demo/dist_tools@4.0.0
```
## About Environment Variables
During HPM Part building, system-provided environment variables are required to define the output and link the required binary files.
These variables are injected into the context for executing scripts based on service requirements.
Therefore, their values can be directly obtained from the scripts. The following environment variables are available:
**Built-in environment variables**
- **DEP_OHOS_BUNDLES**: path of the **ohos_bundles** folder
- **DEP_BUNDLE_BASE**: path of the outermost HPM Part
**Global environment variables**
Global environment variables are defined by the **envs** attribute in **bundle.json**. You can obtain the values of global environment variables from all independent HPM Parts.
```
{
"envs": {
"compileEnv": "arm"
}
}
```
Different parameters can be passed to HPM Parts when introducing dependencies so that the compilation of dependent HPM Parts can meet the requirements of the current HPM Part. The parameters defined in the dependencies can be obtained from the context for executing the corresponding scripts.
```
{
"dependencies": {
"my-bundle": {
"version": "1.0.0",
"mode": "debug"
}
}
}
```
When linking to a binary file, the HPM Part needs to know the file path regarding the dependencies. Therefore, you need to pass the path as an environment variable to the HPM Part for building.
The passed environment variable is in **DEP\_BundleName** format, where **BundleName** indicates the name of the dependent HPM Part, for example, **DEP\_first\_bundle**.
## About Naming and Version Number
1. The name must be lowercase letters or digits and can be separated by underscores (\_), for example, **bundle**, **my\_bundle**, and **json2**.
2. Name of an HPM Part published to [DevEco Marketplace](https://repo.harmonyos.com) must start with the at sign (@) and is separated with the organization name by a slash (/), for example, **@my_org/part_name**.
3. The organization name and part name must be unique and distinguishably different with other names.
4. Names should be easy to understand.
5. An HPM Part version must be in the format of ***majorVersion***.***minorVersion***.***revisionVersion*** or ***majorVersion***.***minorVersion***.***revisionVersion***-***pre-releaseVersion***, for example, **1.0.0** and **1.0.0-beta**. For details, see [https://semver.org](https://semver.org/).
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或