Embedded software development method and device, equipment and storage medium

Abstract

The invention discloses an embedded software development method and device, equipment and a storage medium, and relates to the technical field of embedded software, and the embedded software development method comprises the steps that after a preset code warehouse obtains a project file about a target embedded software project and corresponding label information, a CI / CD assembly line is triggered; determining a containerized environment based on the label information through a CI / CD assembly line, in the containerized environment, determining a project identifier and a project variant identifier based on a configuration file in the project file through a preset cross-platform construction tool, and loading a target file from the project file based on the project identifier and the project variant identifier; and in a containerized environment, executing project construction and project packaging operation about the target embedded software project based on the target file through a preset cross-platform construction tool and a packaging tool to obtain an embedded software product so as to publish the embedded software product. According to the method, the high-efficiency and standardized requirements of software delivery in an embedded scene can be met.

Description

Technical Field

[0001] This invention relates to the field of embedded software technology, and in particular to an embedded software development method, apparatus, device, and storage medium. Background Technology

[0002] In complex embedded scenarios such as the Internet of Things (IoT) and in-vehicle information systems, software delivery needs to adapt to multiple hardware platforms, operating systems, and product models. This requires not only compiling and linking the source code but also integrating build artifacts and non-code resources to form a standardized delivery package. This process relies on cross-compilation and CI / CD (Continuous Integration / Continuous Delivery) workflows, placing extremely high demands on the automation, repeatability, and reliability of delivery. Existing packaging solutions are unable to meet these core requirements.

[0003] The most common approach currently is to use a separate procedural packaging script, which is launched after the main build process ends. This script creates a temporary directory, copies files using hard-coded paths, and compresses and archives the files to complete the delivery. However, this approach has several inherent drawbacks: First, the hard-coded file paths in the script mean that changes to the project directory structure or build target names fail to register, leading to file lookup failures or incorrect file packaging, resulting in extremely poor stability. Second, the packaging logic is completely separated from the build logic, requiring developers to maintain two independent systems simultaneously. Adding new build targets necessitates modifying the script synchronously, increasing the cognitive burden, making it prone to oversights and errors, and increasing maintenance difficulty. Third, adapting to different product models requires copying and modifying the script for differentiated packaging, leading to logical redundancy. Changes to common logic must be synchronized to all script copies, drastically increasing maintenance costs and making it prone to errors, while also limiting scalability. Fourth, it relies on external tools and distributed commands, resulting in significant differences in execution environments, increasing the difficulty of ensuring consistency in the CI / CD environment, and exhibiting low integration with automated processes.

[0004] Therefore, how to meet the needs of efficient and standardized software delivery in embedded scenarios is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide an embedded software development method, apparatus, device, and storage medium that can meet the requirements of efficient and standardized software delivery in embedded scenarios. The specific solution is as follows: Firstly, this application provides an embedded software development method, including: Once the preset code repository obtains the project files and corresponding tag information for the target embedded software project, the CI / CD pipeline is triggered. The project files are files containing the business code of the target embedded software project, a declarative manifest file written based on a preset cross-platform build tool, and a configuration file. The declarative manifest file defines the components required for the embedded software artifacts corresponding to the embedded software project and the installation locations of the components. The configuration file defines the build configuration information required for the embedded software artifacts. The CI / CD pipeline determines the containerized environment corresponding to the target embedded software project based on the tag information. In the containerized environment, the preset cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and loads target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier. The project variant identifier is an identifier that represents the version information and configuration information of the variant within the target embedded software project. In the containerized environment, the preset cross-platform build tool and the packaging tool of the preset cross-platform build tool perform project building and packaging operations on the target embedded software project based on the target file to obtain the corresponding embedded software product, so as to release the embedded software product through the CI / CD pipeline.

[0006] Optionally, the declarative manifest file is a file constructed sequentially through the project packaging start function, component addition function, project packaging end function, and in conjunction with the install command function of a preset cross-platform build tool.

[0007] Optionally, the configuration file is a file that encapsulates the build parameters required for the embedded software artifacts corresponding to the target embedded software project using a preset inheritance mechanism; the build parameters include configuration information of the toolchain for the target embedded software project, project name, project variant name, and build type.

[0008] Optionally, loading target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier includes: The project identifier and the project variant identifier are parsed using the root file in the project file, and it is determined whether there is a target variant corresponding to the project variant identifier, and the determination result is obtained. If the determination result is yes, then the first file search path corresponding to the target variant is determined; If the judgment result is negative, then the root directory of the first file search path is determined as the second file search path; Based on the first file search path or the second file search path, determine from the project file the module list file related to the construction of the target embedded software project and the declarative manifest file related to the packaging of the target embedded software project; The module list file and the declarative manifest file are identified as target files.

[0009] Optionally, determining the containerized environment corresponding to the target embedded software project based on the tag information includes: Based on the tag format of the tag information, the target platform for executing the target embedded software project is determined, and the toolchain for cross-compilation on the target platform is determined; Based on the current base image and the toolchain, a corresponding toolchain image is determined, and the toolchain image is identified as a containerized environment corresponding to the target embedded software project.

[0010] Optionally, before determining the containerization environment corresponding to the target embedded software project based on the tag information through the CI / CD pipeline, the method further includes: When the text configuration file used to build the Docker image changes, determine the changed text configuration file; A new image is built based on the modified text configuration file, and an identity tag and the current version tag are added to the new image to obtain the image with the added tags. The added image is pushed to a preset container image repository so that the added image is identified as the current base image.

[0011] Optionally, the release of the embedded software artifact includes: The version update log of the embedded software artifact is generated using a preset change log generation tool, and a custom release target is created using a preset command-line tool; Based on the custom release target, the version update log, the embedded software artifact, and the current version information of the embedded software artifact are released.

[0012] Secondly, this application provides an embedded software development apparatus, comprising: The information acquisition module is used to trigger the CI / CD pipeline when the preset code repository acquires project files and tag information corresponding to the target embedded software project. The project files are files containing the business code of the target embedded software project, a declarative manifest file written based on a preset cross-platform build tool, and a configuration file. The declarative manifest file defines the components required for the embedded software artifacts corresponding to the embedded software project and the installation locations of the components. The configuration file defines the build configuration information required for the embedded software artifacts. The file loading module is used to determine the containerized environment corresponding to the target embedded software project based on the tag information through the CI / CD pipeline. In the containerized environment, the preset cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and loads target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier. The project variant identifier is an identifier that represents the version information and configuration information of the variant within the target embedded software project. The product release module is used in the containerized environment to perform project building and project packaging operations on the target embedded software project based on the target file using the preset cross-platform build tool and the packaging tool of the preset cross-platform build tool, so as to obtain the corresponding embedded software product and release the embedded software product through the CI / CD pipeline.

[0013] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the aforementioned embedded software development method.

[0014] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned embedded software development method.

[0015] In this application, when a pre-defined code repository obtains project files and corresponding tag information for a target embedded software project, a CI / CD pipeline is triggered. The project files are files containing the business code of the target embedded software project, a declarative manifest file written using a pre-defined cross-platform build tool, and a configuration file. The declarative manifest file defines the components required for the embedded software artifacts corresponding to the embedded software project and their installation locations. The configuration file defines the build configuration information required for the embedded software artifacts. The CI / CD pipeline determines a containerized environment corresponding to the target embedded software project based on the tag information. Within this containerized environment, the pre-defined code repository... A cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and loads target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier. The project variant identifier is an identifier representing the version information and configuration information of a variant within the target embedded software project. In the containerized environment, the preset cross-platform build tool and its packaging tool perform project building and packaging operations on the target embedded software project based on the target files to obtain the corresponding embedded software artifact, which is then released through the CI / CD pipeline. As can be seen from the above, in this application, after the preset code repository obtains the project file of the target embedded software project and the tag information corresponding to that project file, it triggers the CI / CD pipeline. The CI / CD pipeline determines the containerized environment corresponding to the target embedded software project based on the tag information. In this containerized environment, the preset cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and loads target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier. Subsequently, within this containerized environment, a pre-defined cross-platform build tool, in conjunction with its packaging tool, will perform project build and packaging operations on the target embedded software project based on the target files, generating the corresponding embedded software artifact. Finally, the CI / CD pipeline will complete the release of this embedded software artifact. In this way, this application can meet the requirements for efficient and standardized software delivery in embedded scenarios. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 This is a flowchart of an embedded software development method disclosed in this application; Figure 2 This is a schematic diagram illustrating the system composition and data flow principle of an embedded software development method disclosed in this application; Figure 3 This application discloses a declarative list workflow diagram; Figure 4 This is a flowchart of the configuration loading process for one project and its variants disclosed in this application; Figure 5 This is a flowchart illustrating the preset inheritance mechanism during the construction of CMakePresets.json as disclosed in this application; Figure 6 This application discloses a CI / CD automation flowchart; Figure 7 This application discloses a flowchart of a CPack component-based packaging process. Figure 8 This is a schematic diagram of the structure of an embedded software development device disclosed in this application; Figure 9 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Current software delivery solutions suffer from several inherent flaws: First, hard-coded file paths in scripts fail to detect changes in project directory structure or build target names, leading to file lookup failures or incorrect file packaging, resulting in extremely poor stability. Second, the packaging and build logics are completely separated, requiring developers to maintain two independent systems simultaneously. Adding new build targets necessitates script modifications, increasing cognitive burden, making errors prone to oversight, and complicating maintenance. Third, adapting to different product models requires copying and modifying scripts for differentiated packaging, leading to logical redundancy. Changes to common logic must be synchronized across all script copies, drastically increasing maintenance costs, increasing error rates, and hindering scalability. Fourth, reliance on external tools and distributed commands results in significant differences in execution environments, increasing the difficulty of ensuring consistency in CI / CD environments and reducing integration with automated processes. Therefore, this application provides an embedded software development method, apparatus, device, and storage medium that can meet the needs for efficient and standardized software delivery in embedded scenarios.

[0020] See Figure 1 As shown in the figure, an embodiment of the present invention discloses an embedded software development method, including: Step S11: When the preset code repository obtains the project file of the target embedded software project and the tag information corresponding to the project file, the CI / CD pipeline is triggered; the project file is a file containing the business code of the target embedded software project, a declarative manifest file written based on the preset cross-platform build tool, and a configuration file; the declarative manifest file is a file that defines the components required to be included in the embedded software product corresponding to the embedded software project and the installation location of the components; the configuration file is a file that defines the build configuration information required for the embedded software product.

[0021] In this embodiment, during development, developers submit a complete project file, including business code, a declarative manifest file, and configuration files, to the code repository, while simultaneously attaching corresponding tag information to this submission. When the code repository detects that new project files and tag information have been pushed or merged into a specific branch, it automatically triggers the associated continuous integration and continuous delivery pipeline, i.e., the CI / CD pipeline, thereby initiating the subsequent automated build and deployment process.

[0022] It should be noted that the project file is the core carrier of embedded software project development. It not only contains the actual business code that implements the software functions, but also includes key descriptive files that guide the software build process. Specifically, the declarative manifest file is built sequentially using the project packaging startup function, component addition function, and project packaging termination function, combined with the install command function of the preset cross-platform build tool. The configuration file is a file that encapsulates the build parameters required for the embedded software artifacts corresponding to the target embedded software project using a preset inheritance mechanism; these build parameters include configuration information for the toolchain of the target embedded software project, the project name, the project variant name, and the build type.

[0023] Step S12: The CI / CD pipeline determines the containerized environment corresponding to the target embedded software project based on the tag information. In the containerized environment, the preset cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file. Based on the project identifier and the project variant identifier, target files related to project building and project packaging are loaded from the project file. The project variant identifier is an identifier that represents the version information and configuration information of the variant within the target embedded software project.

[0024] In this embodiment, after the CI / CD pipeline is triggered, its primary task is to prepare a repeatable and isolated build environment that matches the target embedded software project. This environment is implemented through containerization technology. Specifically, based on the tag format of the tag information, the target platform for executing the target embedded software project is determined, and the toolchain for cross-compilation on the target platform is determined; based on the current base image and the toolchain, the corresponding toolchain image is determined, and the toolchain image is identified as the containerized environment corresponding to the target embedded software project.

[0025] The current base image is a pre-built container image that includes common build dependencies and the environment. When the text configuration file used to build the Docker image changes, the changed text configuration file is determined; a new image is built based on the changed text configuration file, and an identity tag and the current version tag are added to the new image to obtain the added image; the added image is pushed to a preset container image repository so that the added image is identified as the current base image. Then, when the pipeline performs related operations, it will pull the current base image from the image repository.

[0026] In a containerized environment, the default cross-platform build tool begins operation. The build tool first reads and parses the configuration file within the project file. Based on the build parameters encapsulated in the configuration file, particularly the definitions of the project name and project variant name, the build tool can determine the project identifier and project variant identifier corresponding to this build. The project identifier uniquely distinguishes different software projects, while the project variant identifier distinguishes different variants within the same project, such as software versions targeting different hardware models, with different feature sets, or optimization options. This identifier encapsulates the variant's version details and specific configuration information.

[0027] For subsequent building and packaging, target files related to project building and packaging need to be loaded from the project file. Specifically, the project identifier and the project variant identifier are parsed using the root file in the project file, and it is determined whether a target variant corresponding to the project variant identifier exists. If the determination result is yes, the first file search path corresponding to the target variant is determined; if the determination result is no, the root directory of the first file search path is determined as the second file search path.

[0028] Furthermore, based on the first file search path or the second file search path, a module list file related to the construction of the target embedded software project and a declarative manifest file related to the packaging of the target embedded software project are determined from the project file; the module list file and the declarative manifest file are determined as target files, which provide explicit input for subsequent compilation, linking and package assembly steps.

[0029] Step S13: In the containerized environment, the preset cross-platform build tool and the packaging tool of the preset cross-platform build tool perform project building and project packaging operations on the target embedded software project based on the target file to obtain the corresponding embedded software product, so as to release the embedded software product through the CI / CD pipeline.

[0030] In this embodiment, within a containerized environment that has already loaded the necessary target files, a pre-defined cross-platform build tool begins executing the core build and packaging process, ultimately resulting in a structurally compliant embedded software artifact. At this point, the generation of the software artifact is completed within the container environment. Subsequently, this embedded software artifact, as an output of the CI / CD pipeline, is automatically transferred to the pipeline's release phase. During the release phase, a version update log for the embedded software artifact is generated using a pre-defined change log generation tool, and a custom release target is created using a pre-defined command-line tool. Based on the custom release target, the version update log, the embedded software artifact, and its current version information are released, thereby completing a fully automated delivery process from code changes to a usable software artifact.

[0031] As can be seen from the above, in this application, after the pre-defined code repository obtains the project files and corresponding tag information of the target embedded software project, it will trigger the CI / CD pipeline. The CI / CD pipeline will determine the containerized environment corresponding to the target embedded software project based on the tag information. In this containerized environment, the pre-defined cross-platform build tool will determine the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and load the target files related to project building and project packaging from the project file based on the project identifier and project variant identifier. Subsequently, in this containerized environment, the pre-defined cross-platform build tool will combine with its packaging tool to perform project building and project packaging operations on the target embedded software project based on the target files, generating the corresponding embedded software artifact, and finally the CI / CD pipeline will complete the release of the embedded software artifact. In this way, this application can meet the needs of efficient and standardized software delivery in embedded scenarios.

[0032] The following is combined Figure 2 The schematic diagram shown illustrates the phased process of an embodiment of this application.

[0033] Specifically, the process of this application can be divided into the development stage, the triggering stage, the environment preparation stage, the build and packaging stage, and the release stage.

[0034] The development phase involves developers writing business code locally and configuring declarative manifests (i.e., package.cmake) and build presets (i.e., CMakePresets.json), then committing these configuration files along with the code to the Git repository. The triggering phase automatically triggers the CI / CD pipeline when a developer pushes code to the Git repository and creates a tag in a specific format, such as ids_crrc / v1.0.0. The environment preparation phase involves the CI / CD pipeline matching the preset configuration based on the tag information and starting a containerized environment containing the necessary toolchain, ensuring consistency of the build environment. The build, packaging, and release phases involve the build system (i.e., CMake) loading project configuration information based on build presets in the container environment, then loading the corresponding declarative manifest based on the project identifier and variant identifier, and performing build and packaging operations. The release phase involves the CI / CD pipeline executing a release job after packaging, automatically generating version update logs and creating a GitLab Release using release tools such as git-cliff and glab, and finally uploading the deliverables.

[0035] It's important to note that a declarative manifest is a configuration file that "declares" what a package should include and where it should be installed through predefined, semantically clear commands, rather than "executing" file copying or other operations through procedural scripts. In this invention, this is specifically embodied in the project-specific package.cmake file.

[0036] The build is pre-defined using a standardized configuration file (CMakePresets.json) that predefines and stores multiple different build configurations, such as which project, platform, toolchain to use, and build version.

[0037] A toolchain is a collection of compilers, linkers, and other tools used to compile code for a specific target hardware platform and operating system, such as Linux systems based on ARM (Advanced RISC Machines, a type of processor) architecture. In this invention, it specifically refers to a cross-compilation environment defined through a CMake toolchain file, such as arm-oe-linux-ag35e.cmake.

[0038] A build system is an automated tool used to compile and link source code files into executable programs or libraries. In this invention, it specifically refers to CMake. A packaging tool is a tool used to package build artifacts and metadata, such as executable files, libraries, configuration files, and metadata, into one or more distributable archive files. In this invention, it specifically refers to CPack.

[0039] CI / CD is a software development practice that improves software quality and delivery speed by automating the process of frequently building, testing, and delivering applications. In this invention, it primarily refers to automated processes based on GitLab CI.

[0040] Containerization is a lightweight virtualization technology that packages applications and all their dependencies into a standardized unit for software development, release, and deployment. In this invention, it specifically refers to the Docker environment.

[0041] Project variants refer to different versions or configurations within the same project. For example, an in-vehicle system project may be designed for different car models, such as the T-Box model and the Ivi model, with different combinations and configurations of functional modules.

[0042] The build artifacts can be any file generated by the build system, such as executable files, .so format shared libraries, .a format static libraries, header files, etc.

[0043] The deliverables are the software packages that are ultimately delivered to the user or deployed to the target device. They are usually a compressed archive file, such as .tar.gz, which contains the build artifacts, configuration files, scripts, and documentation for a specific version.

[0044] The core process of the embodiments of this application will be described in detail below.

[0045] Reference Figure 3 As shown, the core of this invention is to deeply integrate the packaging definition with the build system (i.e., CMake), and to define the contents of the deliverables (i.e., the declarative manifest) using a declarative method, rather than the traditional script-based copying operation.

[0046] For declarative manifests, the implementation has a separate `package.cmake` file for each project or project variant, serving as the "manifest" of its deliverables. Declarative manifests are built using declarative functions and components. Declarative functions are a series of high-level semantic helper functions defined in `cmake / packaging_helpers.cmake`. For example, `begin_project_package(project_name)` marks the beginning of a project packaging definition; `add_components_to_package(component_name1 component_name2...)` adds one or more "components" to the final package; and `end_project_package(project_name)` ends the definition, generating the final list of components and passing it to `CPack`.

[0047] The manifest uses the build system's native install() command to define "components". Components can include: install(TARGETS target_name...COMPONENT component_name), which installs build targets such as executables and libraries into the package; install(DIRECTORY directory_name...COMPONENT component_name), which installs directories such as configuration files into the package; and install(FILES file_name...COMPONENT component_name), which installs files such as documentation into the package.

[0048] Furthermore, a declarative manifest, such as projects / ids_skywell / package.cmake, can be illustrated with the following code example: # Start defining the package manifest for the "ids_skywell" project begin_project_package(ids_skywell) # 1. Define and add the "Configuration" component # Install the project's own etc / directory to the etc directory within the package. install(DIRECTORY " {CMAKE_CURRENT_LIST_DIR} / etc / " DESTINATION "etc" COMPONENT skywell_configs ) add_components_to_package(skywell_configs) # 2. Define and add the "Runtime" component # Install the build target ids_skywell (a library file) into the lib directory within the package. install(TARGETS ids_skywell LIBRARY DESTINATION "lib" COMPONENT skywell_runtime ) add_components_to_package(skywell_runtime) # 3. Define and add the "Document" component install(FILES " {CMAKE_CURRENT_LIST_DIR} / README.md" DESTINATION "." COMPONENT skywell_docs ) add_components_to_package(skywell_docs) # End the packaging definition for the "ids_skywell" project end_project_package(ids_skywell) In this way, the manifest only "declares" what to include, while the specific operations of "how" to find, copy, and package are handled automatically by the build system and its packaging tool (CPack). Because install(TARGETS...) directly references the build target, the packaged content always remains consistent with the build output, fundamentally solving the reliability issues caused by hard-coded paths.

[0049] Reference Figure 4 As shown, to support flexible delivery across multiple projects, platforms, and configurations, this invention designs a dynamic configuration loading mechanism that uses project identifiers and project variant identifiers to achieve precise construction of different deliverables. The specific pseudocode for the loaded target structure can be shown below: projects / Project Name 1 (e.g., ids_gac) Module definition file (modules.cmake) Package manifest file (package.cmake) etc / (project configuration files) Project Name 2 (e.g., ids_crrc) Variant name 1 (e.g., ivi) Module definition file (modules.cmake) Package manifest file (package.cmake) etc / (variant configuration files) Variant name 2 (e.g., tbox) Module definition file (modules.cmake) Package manifest file (package.cmake) etc / (variant configuration files) Specifically, the dynamic loading logic includes: the root CMakeLists.txt file dynamically constructs the correct configuration file path based on the values ​​of the variables IDPS_PROJECT_NAME and IDPS_PROJECT_VARIANT, and loads the corresponding modules.cmake (which defines the modules to be built) and package.cmake (which defines the packaged content). The specific implementation code for the loading logic is shown below: # Receive project name and variant name as input option(IDPS_PROJECT_NAME "The project to be configured and packaged""x86_service") option(IDPS_PROJECT_VARIANT "The project variant to be configured and packaged" "") # Dynamically build configuration paths based on project name and variant name set(PROJECT_CONFIG_DIR " {CMAKE_CURRENT_SOURCE_DIR} / projects / {IDPS_PROJECT_NAME}") if(DEFINED IDPS_PROJECT_VARIANT AND NOT IDPS_PROJECT_VARIANT STREQUAL"") set(PROJECT_CONFIG_DIR " {PROJECT_CONFIG_DIR} / {IDPS_PROJECT_VARIANT}") endif() # Load the module definitions and package manifest for the project / variant set(PROJECT_MODULES_FILE " {PROJECT_CONFIG_DIR} / modules.cmake") set(PROJECT_PACKAGE_FILE " {PROJECT_CONFIG_DIR} / package.cmake") if(EXISTS " {PROJECT_MODULES_FILE}") include( {PROJECT_MODULES_FILE}) endif() if(EXISTS " {PROJECT_PACKAGE_FILE}") include(" {PROJECT_PACKAGE_FILE}") endif() Therefore, this mechanism allows the same project to support multiple different variant configurations, such as different car models and different hardware platforms. Only different subdirectories and corresponding configuration files need to be maintained under the projects directory, without having to repeat the entire project structure.

[0050] Reference Figure 5 As shown, this invention centrally manages and solidifies build configurations through the CMakePresets.json file, encapsulating complex build parameters, such as project name, variants, toolchains, and build types, into simple preset names, simplifying the use by developers and CI / CD systems.

[0051] The CMakePresets.json file is built based on a preset inheritance mechanism and configuration solidification. The preset inheritance mechanism uses a layered inheritance design, first inheriting the toolchain configuration, then setting project-specific parameters. Configuration solidification means that each preset solidifies a complete set of configurations, which may include: `inherits`, inheriting the base toolchain configuration; `cacheVariables`, setting variables such as project name, variant name, and build type; and `binaryDir`, specifying the build output directory. The specific implementation code for the preset configuration in the CMakePresets.json file is shown below: { "version": 3, "configurePresets": [ / / Basic toolchain presets (hidden) { "name": "base-arm-zxic", "hidden": true, "generator": "Ninja", "cacheVariables": { "CMAKE_TOOLCHAIN_FILE": " {sourceDir} / cmake / toolchains / arm-zxic-linux.cmake" } }, / / Project-specific presets (public) { "name": "crrc-tbox-release", "displayName": "CRRC (T-Box, ARM ZXIC Release)", "inherits": "base-arm-zxic", / / Inherit toolchain "binaryDir": " {sourceDir} / build / ninja_arm-zxic_release", "cacheVariables": { "IDPS_PROJECT_NAME": "ids_crrc", / / Project name "IDPS_PROJECT_VARIANT": "tbox", / / Variant name "IDPS_PROJECT_VERSION": "1.0.0", / / Version number "CMAKE_BUILD_TYPE": "Release" / / Build type } } ] } Reference Figure 6 As shown, for containerized CI / CD automated release processes, this invention achieves end-to-end automation from code submission to artifact release by deeply integrating the entire delivery process with a containerized CI / CD system, such as GitLab CI / CD, ensuring the consistency, repeatability, and reliability of the build environment.

[0052] It should be noted that, to improve build efficiency and resource reuse, this invention adopts a layered Docker image build strategy to form a toolchain-specific build environment. For the base tool image (i.e., toolchain-base), this image is based on a stable operating system, such as Ubuntu 22.04, and comes pre-installed with build and release tools common to all projects. These tools may include: build tools such as CMake, Ninja, and GCC / G++ compilers; version control such as Git; release tools such as git-cliff for generating version logs and glab for creating GitLab Releases; and other dependencies such as Python, pkg-config, and automake. For the dedicated toolchain image (i.e., toolchain-... <platform>This layered design inherits from the base image and further installs cross-compilation toolchains for specific target platforms. For example, toolchain-ndk is used for Android platforms such as aarch64 and x86_64; toolchain-arm-zxic is used for the ZXIC ARM platform; toolchain-arm-oe-ag35e is used for the AG35E ARM platform; and toolchain-aarch64-gp-linux is used for the GPLinux platform. This layered design ensures that the basic tools only need to be built once, and different platform toolchains only require adding specific content on top of it, significantly improving build efficiency.

[0053] Furthermore, the CI / CD process of this invention is divided into two main stages: the image building stage and the release stage, precisely controlled through the .gitlab-ci.yml file. Specifically, the image building stage is triggered automatically when the Dockerfile in the docker / directory changes; the execution flow is as follows: build a new image based on the changed Dockerfile, tag the image with the latest and commit-sha labels, and push the built image to the Harbor container image repository. The purpose is to ensure that each build uses the latest and consistent environment. Specifically, the release stage is triggered automatically when a Git tag conforming to a specific naming rule, such as ids_crrc / v1.0.0, is pushed; intelligent image selection: the CI system automatically infers the required target platform based on the tag format and selects the corresponding dedicated toolchain image as the execution environment; the build and packaging process is as follows: code checkout, CI Runner pulls the latest code; environment initialization, starts the selected container image; CMake configuration, executes cmake--preset.<preset_name> The preset name is derived from the tag parsing; for building and packaging, execute cmake--build--preset.<preset_name> `--targetpackage` invokes CPack to generate a .tar.gz deliverable based on the project's declarative manifest (i.e., `package.cmake`). Deliverable archiving saves the generated deliverable as an artifact for the CI job. The automated release process includes: environment preparation (starting the base image containing the release tools); dependency retrieval (obtaining deliverables from the preceding build job); version log generation (calling the git-cliff tool to automatically analyze and generate structured version update logs based on the `cliff.toml` configuration file and Git commit history); and GitLabRelease creation (calling the glab tool to automatically create a new Release using the GitLab API, associating version tags, automatically generated logs, and deliverables before release).

[0054] To further simplify the release process, this invention defines a custom `gitlab_release` target in `cmake / gitlab_helpers.cmake`, integrating build, package, and release into a single atomic operation: Dependency: This target depends on the `CPack` package target, ensuring that packaging is always completed before release; Script execution: When `cmake--build--preset` is called... <preset>When `--target gitlab_release` is used, the `cmake / gitlab_release_script.cmake` script will be executed. The script's functions include: verifying the availability of all necessary parameters and tools, automatically obtaining the latest Git tags as the version number, calling `git-cliff` to generate version logs, dynamically searching for the delivery artifact files generated by `CPack`, and calling the `glab` tool to create a `GitLabRelease` and upload the artifacts.

[0055] By utilizing containerization technology, the CI / CD process of this invention offers the following key advantages: environmental consistency—all build and release operations are executed within the same container environment, eliminating compatibility issues caused by environmental heterogeneity; isolation—each job runs in an independent container, avoiding interference between environments; repeatability—the same image and configuration can produce the same results in any Docker-enabled environment; and scalability—the containerized environment is easily scaled within a CI / CD cluster, supporting parallel builds of multiple projects. Through the aforementioned automated CI / CD process, this invention achieves end-to-end automation from code submission to artifact release without any manual intervention, significantly improving delivery efficiency, consistency, and reliability.

[0056] Reference Figure 7 As shown, this invention employs CPack's component-based packaging mechanism, dividing deliverables into different components according to function or type, achieving fine-grained packaging control. Specifically, components are defined as follows: in the package.cmake manifest, the COMPONENT parameter specifies the component to which each install() command belongs; component aggregation is achieved by adding the required components to the final packaging list using the declarative function add_components_to_package(); and unified packaging is performed by CPack merging the contents of all components into a single deliverable based on the final component list. This component-based approach allows developers to flexibly control the content of deliverables, supports on-demand packaging and modular management, and enhances the system's flexibility and scalability.

[0057] By organically combining the above technical solutions, this invention achieves a fully automated and integrated process from code development to product delivery, fundamentally solving the shortcomings of existing technologies in terms of reliability, flexibility, maintainability, and automated integration.

[0058] Accordingly, see Figure 8 As shown, this application embodiment provides an embedded software development apparatus, including: The information acquisition module 11 is used to trigger the CI / CD pipeline after the preset code repository acquires the project file and the tag information corresponding to the target embedded software project. The project file is a file containing the business code of the target embedded software project, a declarative manifest file written based on a preset cross-platform build tool, and a configuration file. The declarative manifest file is a file that defines the components required to be included in the embedded software artifacts corresponding to the embedded software project and the installation locations of the components. The configuration file is a file that defines the build configuration information required for the embedded software artifacts. The file loading module 12 is used to determine the containerized environment corresponding to the target embedded software project based on the tag information through the CI / CD pipeline. In the containerized environment, the preset cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and loads target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier. The project variant identifier is an identifier that represents the version information and configuration information of the variant within the target embedded software project. The product release module 13 is used in the containerized environment to perform project building and project packaging operations on the target embedded software project based on the target file using the preset cross-platform build tool and the packaging tool of the preset cross-platform build tool, so as to obtain the corresponding embedded software product and release the embedded software product through the CI / CD pipeline.

[0059] In some specific implementations, the declarative manifest file is a file constructed sequentially through a project packaging start function, a component addition function, a project packaging end function, and in conjunction with the install command function of a preset cross-platform build tool.

[0060] In some specific implementations, the configuration file is a file that encapsulates the build parameters required for the embedded software artifacts corresponding to the target embedded software project using a preset inheritance mechanism; the build parameters include configuration information of the toolchain for the target embedded software project, project name, project variant name, and build type.

[0061] In some specific embodiments, the file loading module 12 specifically includes: The variant determination unit is used to parse the project identifier and the project variant identifier using the root file in the project file, and determine whether there is a target variant corresponding to the project variant identifier, and obtain the determination result; The first path determination unit is used to determine the first file search path corresponding to the target variant if the judgment result is yes; The second path determination unit is used to determine the root directory of the first file search path as the second file search path if the judgment result is negative. The first file determination unit is used to determine, based on the first file search path or the second file search path, a module list file related to the construction of the target embedded software project and a declarative manifest file related to the packaging of the target embedded software project from the project file; The second file determination unit is used to determine the module list file and the declarative manifest file as target files.

[0062] In some specific embodiments, the file loading module 12 specifically includes: The device determination unit is used to determine the target platform for executing the target embedded software project based on the tag format of the tag information, and to determine the toolchain for cross-compilation on the target platform; The environment determination unit is used to determine the corresponding toolchain image based on the current base image and the toolchain, and to determine the toolchain image as a containerized environment corresponding to the target embedded software project.

[0063] In some specific embodiments, the file loading module 12 further includes: The third file determination unit is used to determine the changed text configuration file when the text configuration file used to build the Docker image is changed; The first image determination unit is used to construct a new image based on the modified text configuration file, and add an identity tag and the current version tag to the new image to obtain the image after addition; The second image determination unit is used to push the added image to a preset container image repository so that the added image can be determined as the current base image.

[0064] In some specific embodiments, the product release module 13 specifically includes: The target creation unit is used to generate version update logs for the embedded software artifacts using a preset change log generation tool, and to create custom release targets using a preset command-line tool. The information publishing unit is used to publish the version update log, the embedded software product, and the current version information of the embedded software product based on the custom publishing target.

[0065] Furthermore, embodiments of this application also disclose an electronic device, Figure 9 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the embedded software development method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0066] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0067] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0068] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs capable of performing the embedded software development method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0069] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed embedded software development method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0070] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0071] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0072] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0073] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0074] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.< / preset> < / platform>

Claims

1. An embedded software development method, characterized in that, include: Once the preset code repository obtains the project files and corresponding tag information for the target embedded software project, the CI / CD pipeline is triggered. The project files are files containing the business code of the target embedded software project, a declarative manifest file written based on a preset cross-platform build tool, and a configuration file. The declarative manifest file defines the components required for the embedded software artifacts corresponding to the embedded software project and the installation locations of the components. The configuration file defines the build configuration information required for the embedded software artifacts. The CI / CD pipeline determines the containerized environment corresponding to the target embedded software project based on the tag information. In the containerized environment, the preset cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and loads target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier. The project variant identifier is an identifier that represents the version information and configuration information of the variant within the target embedded software project. In the containerized environment, the preset cross-platform build tool and the packaging tool of the preset cross-platform build tool perform project building and packaging operations on the target embedded software project based on the target file to obtain the corresponding embedded software product, so as to release the embedded software product through the CI / CD pipeline.

2. The embedded software development method according to claim 1, characterized in that, The declarative manifest file is constructed sequentially through the project packaging start function, component addition function, project packaging end function, and in conjunction with the install command function of the preset cross-platform build tool.

3. The embedded software development method according to claim 1, characterized in that, The configuration file is a file that encapsulates the build parameters required for the embedded software artifacts corresponding to the target embedded software project using a preset inheritance mechanism; the build parameters include the toolchain configuration information, project name, project variant name, and build type of the target embedded software project.

4. The embedded software development method according to claim 1, characterized in that, The loading of target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier includes: The project identifier and the project variant identifier are parsed using the root file in the project file, and it is determined whether there is a target variant corresponding to the project variant identifier, and the determination result is obtained. If the determination result is yes, then the first file search path corresponding to the target variant is determined; If the judgment result is negative, then the root directory of the first file search path is determined as the second file search path; Based on the first file search path or the second file search path, determine from the project file the module list file related to the construction of the target embedded software project and the declarative manifest file related to the packaging of the target embedded software project; The module list file and the declarative manifest file are identified as target files.

5. The embedded software development method according to claim 1, characterized in that, The step of determining the containerized environment corresponding to the target embedded software project based on the tag information includes: Based on the tag format of the tag information, the target platform for executing the target embedded software project is determined, and the toolchain for cross-compilation on the target platform is determined; Based on the current base image and the toolchain, a corresponding toolchain image is determined, and the toolchain image is identified as a containerized environment corresponding to the target embedded software project.

6. The embedded software development method according to claim 5, characterized in that, Before determining the containerized environment corresponding to the target embedded software project based on the tag information through the CI / CD pipeline, the process further includes: When the text configuration file used to build the Docker image changes, determine the changed text configuration file; A new image is built based on the modified text configuration file, and an identity tag and the current version tag are added to the new image to obtain the image with the added tags. The added image is pushed to a preset container image repository so that the added image is identified as the current base image.

7. The embedded software development method according to any one of claims 1 to 6, characterized in that, The release of the embedded software artifact includes: The version update log of the embedded software artifact is generated using a preset change log generation tool, and a custom release target is created using a preset command-line tool; Based on the custom release target, the version update log, the embedded software artifact, and the current version information of the embedded software artifact are released.

8. An embedded software development device, characterized in that, include: The information acquisition module is used to trigger the CI / CD pipeline when the preset code repository acquires project files and tag information corresponding to the target embedded software project. The project files are files containing the business code of the target embedded software project, a declarative manifest file written based on a preset cross-platform build tool, and a configuration file. The declarative manifest file defines the components required for the embedded software artifacts corresponding to the embedded software project and the installation locations of the components. The configuration file defines the build configuration information required for the embedded software artifacts. The file loading module is used to determine the containerized environment corresponding to the target embedded software project based on the tag information through the CI / CD pipeline. In the containerized environment, the preset cross-platform build tool determines the project identifier and project variant identifier corresponding to the target embedded software project based on the configuration file in the project file, and loads target files related to project building and project packaging from the project file based on the project identifier and the project variant identifier. The project variant identifier is an identifier that represents the version information and configuration information of the variant within the target embedded software project. The product release module is used in the containerized environment to perform project building and project packaging operations on the target embedded software project based on the target file using the preset cross-platform build tool and the packaging tool of the preset cross-platform build tool, so as to obtain the corresponding embedded software product and release the embedded software product through the CI / CD pipeline.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the embedded software development method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the embedded software development method as described in any one of claims 1 to 7.

Images