Code compiling method, code compiling device, electronic equipment and storage medium

Abstract

This application provides a code compilation method, a code compilation apparatus, an electronic device, and a storage medium. The code compilation method, applied in the field of computer technology, includes: obtaining a target code repository list, which includes identification information for M code repositories, where the M repositories store code files to be compiled; classifying the M code repositories into L repository groups, each repository group including identification information for at least one code repository; determining N target repository groups from the L repository groups in response to target compilation instructions; and compiling the target code files corresponding to the N target repository groups to obtain the compilation results of the target code files. This code compilation method provides a split compilation strategy, performing partial compilation only on a portion of the code files in the code repository while leaving the remaining code files uncompiled, significantly reducing code compilation time and server computing power consumption.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a code compilation method, code compilation apparatus, electronic device, and storage medium in the field of computer technology. Background Technology

[0002] Currently, in the software product development process, the source code written by developers is usually a text file written in various programming languages. When processing it, computer devices typically need to convert the source code into binary code that the computer devices can execute; this process is called "code compilation".

[0003] Currently, during the code compilation process, developers typically trigger a full compilation after submitting code, resulting in long compilation times and high resource consumption. Summary of the Invention

[0004] This application provides a code compilation method, a code compilation device, an electronic device, and a storage medium. The code compilation method can provide a split compilation strategy, which only compiles a portion of the code files in the code repository, while leaving the remaining code files uncompiled, thereby significantly reducing code compilation time and server computing power consumption.

[0005] The first aspect of this application provides a code compilation method, which includes: obtaining a target code repository list, the target code repository list including identification information of M code repositories, the M code repositories being used to store various code files to be compiled, where M is a positive integer greater than 1; classifying the M code repositories to obtain L repository groups of different categories, each repository group including identification information of at least one code repository, where L is a positive integer greater than 1; in response to a target compilation instruction, determining N target repository groups corresponding to the target compilation instruction from the L repository groups, where N is a positive integer greater than or equal to 1 and less than or equal to L; and compiling the target code files corresponding to the N target repository groups to obtain the compilation result of the target code files.

[0006] In the above technical solution, this application provides a code compilation method. The specific implementation process of this code compilation method is as follows: First, obtain a list of target code repositories for this compilation. This list includes identification information for M code repositories, which are used to store the code files to be compiled. Further, classify the M code repositories into L repository groups, each repository group including identification information for at least one code repository. This classification of code repositories pre-divides them into multiple independent repository groups according to functional modules. The code files in each repository group are relatively independent, providing a foundation for subsequent separate compilation. Finally, upon receiving the target compilation instruction, determine N target repository groups from the L repository groups and compile the target code files in these N target repository groups. This method only compiles the code files of a partial repository group within the L repository groups, without requiring a full compilation of all code files in the L repository groups. This enables partial or on-demand compilation of code files, significantly reducing compilation time and resource consumption, and improving compilation efficiency.

[0007] In conjunction with the first aspect, in some possible implementations, the M code repositories are classified to obtain L repositories of different categories, including: obtaining attribute information of the M code repositories; and classifying the M code repositories according to the attribute information of the M code repositories to obtain the L repositories.

[0008] Combining the first aspect and the above implementation methods, in some possible implementations, the L repository groups include a kernel repository group, a hardware abstraction layer repository group, an extension repository group, and a system repository group. The attribute information includes storage paths and compilation configuration files. Based on the attribute information of the M code repositories, the M code repositories are classified to obtain the L repository groups, including: generating the kernel repository group based on the identification information of U code repositories among the M code repositories, where U is a positive integer greater than or equal to 1 and less than or equal to M, and the storage paths of the U code repositories are all preset kernel paths; generating the hardware abstraction layer repository group based on the identification information of V code repositories among the M code repositories, where V is a positive integer greater than or equal to 1 and less than or equal to M. The V code repositories are positive integers equal to 1 and less than or equal to M. The compilation configuration files of the V code repositories include a preset hardware abstraction layer identifier field. Based on the identifier information of the W code repositories among the M code repositories, the extended repository group is generated, where W is a positive integer greater than or equal to 1 and less than or equal to M. The compilation configuration files of the W code repositories include a preset extended identifier field. Based on the identifier information of the T code repositories among the M code repositories, the system repository group is generated, where T is a positive integer greater than or equal to 1 and less than or equal to M. The T code repositories are the code repositories other than the U code repositories, the V code repositories, and the W code repositories among the M code repositories. The sum of U, V, T, and W is greater than or equal to M.

[0009] In the above technical solution, this application divides all code repositories into four independent repository groups based on the storage path and compilation configuration file of the code repository. This enables automatic classification of code repositories, which facilitates differentiated compilation and maintenance by group, thereby providing a separate code management strategy and avoiding the time-consuming problem caused by full compilation.

[0010] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, before determining the N target repository groups corresponding to the target compilation instruction from the L repository groups in response to the target compilation instruction, the code compilation method further includes: generating group identifiers for the L repository groups; and determining the N target repository groups corresponding to the target compilation instruction from the L repository groups in response to the target compilation instruction includes: parsing the target compilation instruction to obtain the identifier information of the target code repository corresponding to the target compilation instruction or the group identifier corresponding to the target compilation instruction; matching the identifier information of the target code repository with the identifier information of each code repository in the L repository groups, and determining the repository group to which the identifier information of the successfully matched target code repository belongs as the N target repository groups; or, determining the repository group associated with the group identifier corresponding to the target compilation instruction as the N target repository groups.

[0011] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the compilation of the target code files corresponding to the N target repository groups to obtain the compilation result of the target code files includes: for any target repository group among the N target repository groups, determining whether the multiple candidate code files corresponding to the target repository group include the modified code file; if the multiple candidate code files include the modified code file, determining the target code file from the multiple candidate code files, and compiling the target code file to obtain the compilation result of the target code file.

[0012] In the above technical solution, the modification status of each candidate code file in the target repository group is checked before the code compilation operation is performed. The compilation is only performed when there are modified code files in the target repository group. This can effectively filter out invalid compilation tasks in scenarios where there is no code modification and reduce the waste of resources caused by unnecessary compilation operations.

[0013] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, determining whether the multiple candidate code files corresponding to the target repository group include the modified code file includes: for any candidate code file among the multiple candidate code files, obtaining the current hash value of the candidate code file and the historical hash value at the end of the last compilation; if the current hash value is the same as the historical hash value, determining that the multiple candidate code files do not include the modified code file; if the current hash value is different from the historical hash value, determining that the multiple candidate code files include the modified code file, and identifying the candidate code file as the modified code file.

[0014] In the above technical solution, this application determines whether the candidate code file has been modified by comparing the hash value of the code file. It can accurately identify whether the code file has changed content compared to the end of the previous compilation, effectively filter out the code file that really needs to be compiled, and improve the accuracy and reliability of compilation.

[0015] In combination with the first aspect and the above implementation methods, in some possible implementation methods, determining the target code file from the plurality of candidate code files includes: obtaining the global dependency tree corresponding to the target repository group, the global dependency tree being used to represent the dependency relationships between the plurality of candidate code files; determining at least one candidate code file among the plurality of candidate code files that has a dependency relationship with the modified code file based on the global dependency tree corresponding to the target repository group; and determining the modified code file and the at least one candidate code file as the target code file.

[0016] In the above technical solution, when determining the target code file, this application identifies the dependency relationship between each code file in the target repository group through the global dependency tree of the target repository group, thereby accurately identifying the candidate code file in the target repository group that has a strong dependency relationship with the modified code file and incorporating it into the target code file. This can avoid compilation errors caused by missing dependencies and improve the success rate of this compilation.

[0017] A second aspect of this application provides a code compilation apparatus, comprising: an acquisition module for acquiring a target code repository list, the target code repository list including identification information of M code repositories, the M code repositories being used to store various code files to be compiled, where M is a positive integer greater than 1; a determination module for classifying the M code repositories to obtain L repository groups of different categories, each repository group including identification information of at least one code repository, where L is a positive integer greater than 1; the determination module is further configured to, in response to a target compilation instruction, determine N target repository groups corresponding to the target compilation instruction from the L repository groups, where N is a positive integer greater than or equal to 1 and less than or equal to L; and a compilation module for compiling the target code files corresponding to the N target repository groups to obtain the compilation result of the target code files.

[0018] In conjunction with the second aspect, in some possible implementations, the determining module is specifically used to: obtain the attribute information of the M code repositories; classify the M code repositories according to the attribute information of the M code repositories to obtain the L repository groups.

[0019] Combining the second aspect and the above implementation methods, in some possible implementations, the L repository groups include a kernel repository group, a hardware abstraction layer repository group, an extension repository group, and a system repository group. The attribute information includes storage paths and compilation configuration files. The determining module is further configured to: generate the kernel repository group based on the identification information of U code repositories among the M code repositories, where U is a positive integer greater than or equal to 1 and less than or equal to M, and the storage paths of the U code repositories are all preset kernel paths; generate the hardware abstraction layer repository group based on the identification information of V code repositories among the M code repositories, where V is a positive integer greater than or equal to 1 and less than or equal to M, and the storage paths of the V code repositories are all preset kernel paths; The compilation configuration file of each code repository includes a preset hardware abstraction layer identifier field; based on the identifier information of W code repositories out of the M code repositories, the extended repository group is generated, where W is a positive integer greater than or equal to 1 and less than or equal to M, and the compilation configuration file of the W code repositories includes a preset extended identifier field; based on the identifier information of T code repositories out of the M code repositories, the system repository group is generated, where T is a positive integer greater than or equal to 1 and less than or equal to M, and the T code repositories are the code repositories other than the U code repositories, the V code repositories, and the W code repositories out of the M code repositories, and the sum of U, V, T and W is greater than or equal to M.

[0020] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, before determining the N target repository groups corresponding to the target compilation instruction from the L repository groups in response to the target compilation instruction, the determining module is further configured to: generate group identifiers for the L repository groups; and the determining module is further configured to: parse the target compilation instruction to obtain the identifier information of the target code repository corresponding to the target compilation instruction or the group identifier corresponding to the target compilation instruction; match the identifier information of the target code repository with the identifier information of each code repository in the L repository groups, and determine the repository group to which the identifier information of the successfully matched target code repository belongs as the N target repository groups; or, determine the repository group associated with the group identifier corresponding to the target compilation instruction as the N target repository groups.

[0021] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the compilation module is specifically used to: for any target repository group among the N target repository groups, determine whether the multiple candidate code files corresponding to the target repository group include the modified code file; if the multiple candidate code files include the modified code file, determine the target code file from the multiple candidate code files, and compile the target code file to obtain the compilation result of the target code file.

[0022] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the compilation module is further configured to: for any candidate code file among the plurality of candidate code files, obtain the current hash value of the candidate code file and the historical hash value at the end of the last compilation; if the current hash value is the same as the historical hash value, determine that the plurality of candidate code files does not include the modified code file; if the current hash value is different from the historical hash value, determine that the plurality of candidate code files includes the modified code file, and identify the candidate code file as the modified code file.

[0023] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the compilation module is further configured to: obtain the global dependency tree corresponding to the target repository group, the global dependency tree being used to represent the dependency relationships between the multiple candidate code files; determine at least one candidate code file among the multiple candidate code files that has a dependency relationship with the modified code file based on the global dependency tree corresponding to the target repository group; and determine the modified code file and the at least one candidate code file as the target code file.

[0024] A third aspect of this application provides an electronic device including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to execute the code compilation method in the first aspect or any possible implementation thereof.

[0025] The fourth aspect of this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to execute the code compilation method in the first aspect or any possible implementation thereof.

[0026] The fifth aspect of this application provides a computer-readable storage medium storing computer program code, which, when run on a computer, causes the computer to execute the code compilation method in the first aspect or any possible implementation thereof. Attached Figure Description

[0027] Figure 1 This is a schematic flowchart of a code compilation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a code organization method for a QSSI architecture provided in an embodiment of this application; Figure 3 This is a schematic flowchart of another code compilation method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a code compilation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0030] Before introducing the methods of the embodiments of this application, the technical terms that may be involved in the embodiments of this application will be explained first.

[0031] Code compilation refers to the process of converting source code written in a programming language into binary instructions that can be understood by a machine.

[0032] Android 14 is the 14th official mobile or automotive embedded operating system version released by Google's Android Open Source Project (AOSP). It is the underlying system source code in the code compilation process.

[0033] Code repository: refers to a systematic storage space for storing, managing, and tracking code changes.

[0034] Code gates: a code quality assurance measure designed to ensure that code submitted by developers meets certain requirements before it can be merged into the code repository. These requirements include code compilation success, unit test coverage, and static code analysis. Code compilation is usually the core process in code gates.

[0035] Image file: refers to a binary file that packages a type of system or data content according to a specific file system format. In other words, an image file is a file that can be burned by packaging binary code generated from code compilation into a programmable file according to certain rules.

[0036] Git: A distributed version control system, it is a low-level tool used to manage source code versions, record code modifications, and facilitate collaborative code development by multiple people.

[0037] Gerrit is a web-based platform for code review and commit management built on top of Git repositories, specifically designed to standardize the Git code ingestion process.

[0038] Manifest file: This usually refers to the manifest file used by the Repo tool in AOSP. Its purpose is to describe which Git repositories make up the entire Android source code. The Manifest file is essentially a manifest file in Extensible Markup Language (XML) format.

[0039] After explaining the technical terms used in the embodiments of this application, the application scenarios of the embodiments of this application are described below.

[0040] Currently, in the development of software products such as embedded systems, in-vehicle terminals, and smart terminals, developers typically use various programming languages ​​(e.g., C++, Java, Python) to write business logic, hardware adaptation, and system framework content, ultimately resulting in completed source code. It should be understood that source code is essentially a plain text file with a fixed syntax, which cannot be directly recognized and parsed by computer devices. Computer devices can only read and execute binary machine instructions composed of 0s and 1s. Therefore, before software packaging, firmware flashing, and functional verification, developers need to use compilation tools to perform multiple rounds of syntax parsing and compilation of the source code, converting the readable source code into a binary program that can be loaded, scheduled, and run by computer hardware. This process is also called code compilation.

[0041] Currently, when compiling code, developers have to wait for the entire compilation to be completed after submitting code to the code gate system before subsequent code merging and version building can proceed, resulting in a long development cycle and high resource consumption.

[0042] For example, for large-scale complete device source code projects like the Android system built on AOSP, the entire project often contains hundreds or thousands of Git code repositories (i.e., code repositories managed by Git). In the traditional R&D delivery process, after developers complete code modifications locally, they submit them to the Gerrit platform via Git to trigger code gate verification. By default, the platform will pull the source code stored in all code repositories within the project's master manifest and perform a full compilation of the entire device project.

[0043] The above full compilation has the following obvious problems: First, the compilation process is time-consuming. A single full compilation of a large-scale automotive Android 14 source code project typically takes several hours. Every time a developer submits a minor code change (for example, modifying only one or two lines of logic code in a single repository), they have to wait for the entire compilation process to finish before they can obtain the access control verification results, which severely reduces code development efficiency.

[0044] Secondly, compilation consumes huge resources. Compiling the entire machine will occupy a lot of server computing power, resulting in excessive server load, affecting the execution efficiency of other tasks or causing other tasks to time out.

[0045] In view of this, embodiments of this application provide a code compilation method that can provide a split compilation strategy, which only performs partial compilation on a portion of the code files in the code repository, while leaving the remaining code files uncompiled, thereby significantly reducing code compilation time and server computing power consumption.

[0046] After introducing the application scenarios of the embodiments of this application, the following will be conducted through... Figure 1The method implementation process of the embodiments of this application will be described in detail.

[0047] It should be understood that this method is applied to an electronic device, which may be a server, terminal device, personal computer device, any node device in a cloud server cluster, etc. The embodiments of this application do not limit the electronic device that executes the method.

[0048] Figure 1 This is a schematic flowchart of a code compilation method provided in an embodiment of this application.

[0049] For example, such as Figure 1 As shown, the code compilation method 100 includes the following steps 101 to 104.

[0050] 101. Obtain the target code repository list. The target code repository list includes the identification information of M code repositories. The M code repositories are used to store the code files to be compiled. M is a positive integer greater than 1.

[0051] It should be understood that the code compilation method and its principles provided in this application are cross-platform universal. The current embodiment uses the Qualcomm Single System Image (QSSI) structure of the Qualcomm platform as an example, and uses the specific code organization and construction rules under this architecture for introduction and explanation. In other alternative implementations, this method can also be applied to Android source code projects using other chip architectures such as MediaTek Inc. (MTK), Unisoc, and HiSilicon platforms.

[0052] It should also be understood that the foregoing description uses the Android 14 version of AOSP source code as an example. This method is also applicable to other versions of Android system source code projects, such as Android 15 and Android 13, and this application embodiment does not limit this. In addition, besides being applicable to source code compilation scenarios of the Android system, the overall implementation principle of the method in this application embodiment can also be applied to other embedded system source code compilation scenarios based on the Linux kernel.

[0053] In the following description of the embodiments of this application, the source code project of Android 14 under the QSSI architecture will be used as an example to explain in detail the implementation process of the method of the embodiments of this application.

[0054] It should be understood that starting with Android version 12, the amount of Android code has increased significantly, which has led to a significant increase in compilation resources and time during full compilation. The following will explain... Figure 2 Explain this issue.

[0055] Figure 2This is a schematic diagram of the code organization method of a QSSI architecture provided in an embodiment of this application.

[0056] For example, such as Figure 2 As shown, the Qualcomm Snapdragon S ChipCode and Qcom S Chip Code represent the complete set of code based on Qualcomm chips in Android 12 (S). The Qcom R ChipCode represents the complete set of code based on Qualcomm chips in Android 11 (R).

[0057] The Qcom S Chip Code collection specifically includes the following code repositories: Qualcomm Single System Image (qssi) 12 code repository, qssi 12 Proprietary code repository, qssi 12 Build Profile / Blueprint (bp) code repository, qssi 12 Vendor code repository, and Vendor Proprietary code repository.

[0058] The Qcom R Chip Code collection specifically includes the following code repositories: qssi11 code repository, qssi 11Proprietary code repository, qssi11 bp code repository, qssi 11 Vendor code repository, and vendor-specific code repositories.

[0059] Based on the differences in code organization between the different Android versions mentioned above, the code for Android 12 is composed of qssi12, qssi12proprietary, qssi12 bp, qssi12 vendor, vendor(proprietary), qssi11, and qssi11proprietary, which nearly doubles the overall code size.

[0060] like Figure 2 As shown, the branch management strategy for Android 12 (S) uses multiple code branches for maintenance, including the qssi branch for S version and the vendor branch for S version.

[0061] The S version's qssi branch is a new code branch created based on the S version, consisting of two code repositories: qssi12 and qssi12proprietary. The S version's vendor branch consists of the remaining three code repositories: qssi12 bp, qssi12 vendor, and vendor(proprietary), as well as the two code repositories corresponding to the R version: qssi11 and qssi11 proprietary.

[0062] Specifically, the vendor branch of version S is a new branch derived from the development branch (devbranch) of version R at the version integration (VI) node.

[0063] As can be seen from the above description, the amount of code in Android 12 is significantly larger than that in Android 11.

[0064] It should be understood that in the actual code compilation process, electronic devices usually need to first obtain the compilation configuration file of the code repository, such as the Android.bp file or the Android.mk file. Then, based on the compilation configuration file of the code repository, the electronic device reads the source code listing, compilation parameters and module dependencies declared in the compilation configuration file, and converts and outputs the build.ninja file after converting the build topology of all compilation modules in the entire code repository for subsequent compilation.

[0065] With the significant increase in code size in Android 12, the number of configuration files that electronic devices need to parse during the full compilation process also increases, resulting in a noticeable increase in parsing time. This makes the final conversion and generation of Ninja build rules take longer, and the overall code compilation time also increases accordingly.

[0066] Based on this, taking the source code of Android 14 as an example, when the source code is compiled separately using the method of this application embodiment, the workload of code compilation can be effectively reduced.

[0067] Specifically, in the implementation process of this application embodiment, the electronic device first needs to obtain the current target code repository manifest, i.e., the Manifest manifest, in order to determine the scope of code compilation in this compilation process.

[0068] The manifest can be understood as an XML file containing identification information for M code repositories to be compiled. The M repositories store the code files to be compiled, where M is a positive integer greater than 1.

[0069] Optionally, the identification information of the code repository can be, for example, the name, path, or unique number of the code repository.

[0070] For example, during code compilation, developers pre-set up the compilation environment and configure the manifest file, specifying the specific repositories required for this compilation. The manifest file is stored in a designated directory of a dedicated manifest Git repository hosted on the Gerrit platform. Based on this, electronic devices can access the Gerrit platform's repository or directory via the Git protocol and read the manifest file in that directory. The manifest includes identification information for the M code repositories required for this compilation.

[0071] For example, the identification information of a code repository can be represented in the Manifest as follows:<projectpath="packages / apps / Settings" name="platform / packages / apps / Settings" / > Here, `path` represents the local storage path of the code repository, and `name` represents the unique identifier of the code repository on the remote server. Each code repository stores the source code files for different functional modules, and the M code repositories store all the code files to be compiled in this operation.

[0072] The local storage path (path) and the unique identifier (name) of the code repository on the remote server serve the following purposes: The code repository's name is the unique identifier stored in the Git repository, used by the electronic device to pull the source code of the corresponding code repository from the remote server (i.e., the Gerrit server) to the corresponding local path. Therefore, the code repository's path is the local root directory where the electronic device pulls the corresponding source code based on the code repository's name; that is, the storage location of the source code on the electronic device's local machine.

[0073] 102. Classify the M code repositories to obtain L repositories groups of different categories. Each repository group includes the identification information of at least one code repository, where L is a positive integer greater than 1.

[0074] After obtaining the identification information of all code repositories to be compiled during this compilation process, the electronic device can classify the M code repositories into L different repository groups (or repository groups) during the separate compilation process. Based on this, when compilation is needed later, the electronic device can only compile all the source code under a certain repository group.

[0075] Specifically, the process of classifying M code repositories into L repositories is as follows.

[0076] One possible implementation involves classifying the M code repositories into L groups of repositories belonging to different categories, including: Retrieve attribute information for M code repositories; Based on the attribute information of M code repositories, the M code repositories are classified to obtain L repository groups.

[0077] It should be understood that the classification of the M code repositories is mainly based on the attribute information of the M code repositories, which represents the basic information of the code repositories. Optionally, the attribute information includes, but is not limited to, the identification information of the code repository, the local storage path (hereinafter referred to as "storage path"), and the compilation configuration file of the code repository.

[0078] For example, after obtaining the Manifest, an electronic device can retrieve the identification information and local storage path of each code repository from the Manifest.

[0079] The build configuration file refers to the module build description file in the Android build system, which uses Android.mk or Android.bp as its carrier or suffix. It is not used to carry business function logic, but only to declare the compilation constraints of the compiled module.

[0080] A code repository typically contains multiple levels of directories, each containing various compiled modules. A single repository may contain dozens or even hundreds of compiled modules. Each compiled module corresponds to multiple source code files, which are linked together by a configuration file. That is, usually, one compiled module corresponds to one or more configuration files, but in some scenarios, a single configuration file can define the compilation rules and dependencies for multiple compiled modules simultaneously.

[0081] After obtaining the identification information of the code repository, the electronic device can retrieve the compilation configuration files of each code repository from the Git repository of the Gerrit server one by one based on the identification information.

[0082] After obtaining the attribute information of each code repository, the above classification process is as follows.

[0083] In one possible implementation, the L repository groups include a kernel repository group, a hardware abstraction layer repository group, an extension repository group, and a system repository group. Attribute information includes storage paths and build configuration files. Based on the attribute information of the M code repositories, the M code repositories are classified to obtain the L repository groups, including: Based on the identification information of U code repositories out of M code repositories, generate a kernel repository group, where U is a positive integer greater than or equal to 1 and less than or equal to M, and the storage paths of the U code repositories are all preset kernel paths; Based on the identification information of V code repositories out of M code repositories, a hardware abstraction layer repository group is generated, where V is a positive integer greater than or equal to 1 and less than or equal to M, and the compilation configuration files of the V code repositories include a preset hardware abstraction layer identification field. Based on the identification information of W code repositories out of M code repositories, an extended repository group is generated, where W is a positive integer greater than or equal to 1 and less than or equal to M, and the compilation configuration files of the W code repositories include a preset extended identifier field. Based on the identification information of T code repositories out of M code repositories, a system repository group is generated, where T is a positive integer greater than or equal to 1 and less than or equal to M, and the T code repositories are the code repositories other than U, V and W code repositories out of the M code repositories, and the sum of U, V, T and W is greater than or equal to M.

[0084] In this embodiment, taking the Android 14 source code on the Qualcomm platform as an example, the M code repositories can be divided into 4 repository groups, i.e., L=4. The 4 repository groups include the kernel (krn) repository group, the hardware abstraction layer (hal) repository group, the extension (vext) repository group, and the system (sys) repository group. In other source code architectures, the total number of repository groups L can also be reduced or increased according to actual needs, and the division method of each repository group can also be adaptively adjusted. This embodiment does not limit this.

[0085] Among them, the krn repository group refers to a collection of code repositories used to store the source code of the Linux kernel; the hal repository group refers to a collection of code repositories used to store the source code of hardware drivers and abstract interfaces; the vext repository group refers to a collection of code repositories used to store the source code of vendor-customized functions; and the sys repository group refers to a collection of code repositories used to store the source code of the system's core services.

[0086] Specifically, the division of the above four repository groups is based on the following: First, the electronic device determines whether the path field of the code repository in the Manifest contains a preset kernel path (e.g., platform_kernel). In other words, it checks whether the path field contains the preset kernel path. If the storage path of the code repository contains the preset kernel path, it means that these code repositories meet the kernel grouping criteria for being assigned to the krn repository group. Further, the electronic device combines the identification information of these U code repositories that meet the kernel grouping criteria to obtain the krn repository group, that is, assigning the identification information of the U code repositories to the krn repository group.

[0087] Secondly, for the HAL repository group, the electronic device traverses the compilation configuration files of each code repository and determines whether the compilation configuration file contains a preset Hardware Abstraction Layer (HAL) identifier field. If the compilation configuration file contains the preset HAL identifier field, the identifier information of that code repository is assigned to the HAL repository group.

[0088] Specifically, in this embodiment of the application, the preset hardware abstraction layer identifier field of different versions of the compilation configuration file is also different.

[0089] Optionally, the build configuration file versions include the older version – the Android.mk configuration file – and the newer version – the Android.bp configuration file. The older version refers to the format used in earlier versions of the Android source code, primarily those built using the GNU make tool, and exists in the source code of Android 7 through Android 11. The newer version refers to the format used in newer versions of the Android source code, primarily those generated by the Soong build system, and exists in the source code of Android 12 and above. In the Android 14 source code, both versions of the build configuration file may coexist.

[0090] The default hardware abstraction layer identifier field in the old build configuration file could be `LOCAL_VENDOR_MODULE := true`. The default hardware abstraction layer identifier field in the new build configuration file is `vendor : true`. Regardless of the version, both the `LOCAL_VENDOR_MODULE` and `vendor` fields indicate that the module belongs to a vendor-specific hardware adaptation module. A value of `true` indicates that the module is an explicitly declared hardware abstraction layer module by the developer, and the compilation artifacts need to be packaged into the `vendor` image partition. The `vendor` image partition is a dedicated image partition in the Android architecture for storing hardware drivers and abstract interface-related files. Correspondingly, the code repository corresponding to the build configuration file containing this default hardware abstraction layer identifier field is assigned to the HAL repository group.

[0091] It should be understood that a code repository may contain more than one build configuration file. When determining whether a code repository can be assigned to a HAL repository group, for any build configuration file in a code repository, as long as the electronic device determines that the build configuration file contains the preset hardware abstraction layer identifier field corresponding to its version, it can determine that the code repository meets the HAL repository group assignment conditions and assign its identifier information to the HAL repository group. Whether other build configuration files in the code repository contain the preset hardware abstraction layer identifier field does not affect the assignment result of the code repository.

[0092] By performing the above judgment on the compilation configuration files of M code repositories, the identification information of V code repositories that meet the HAL repository group division conditions can be assigned to the HAL repository group.

[0093] For the vext repository group, the electronic device also iterates through the build configuration files of each code repository to determine whether the build configuration file contains a preset extended identifier field. If the build configuration file contains the preset extended identifier field, the identifier information of that code repository is assigned to the vext repository group.

[0094] Similar to the principle of dividing HAL repository groups, the default extended identifier fields of different versions of the compilation configuration files also differ according to the version of the compilation configuration files.

[0095] Specifically, the default extension identifier field in the old build configuration file could be LOCAL_SYSTEM_EXT_MODULE := true. The corresponding default extension identifier field in the new build configuration file is system_ext_specific : true. Regardless of the build configuration file version, both the LOCAL_SYSTEM_EXT_MODULE and system_ext_specific fields indicate that the module belongs to the system extension layer. A value of true for this field indicates that the module is a system extension module explicitly declared by the developer. The compilation artifacts of this module need to be packaged into the system_ext partition image, and the code repository containing this type of compiled module will be uniformly grouped into the vext repository group.

[0096] Similarly, a code repository may contain more than one build configuration file. When determining whether a code repository can be assigned to the vext repository group, for any build configuration file in a code repository, as long as the electronic device determines that the build configuration file contains the preset extended identifier field corresponding to its version, it can determine that the code repository meets the assignment conditions of the vext repository group and assign its identifier information to the vext repository group. Whether other build configuration files in the code repository contain the preset extended identifier field does not affect the assignment result of the code repository.

[0097] By performing the above judgment on the compilation configuration files of M code repositories, the identification information of W code repositories that meet the vext repository group division conditions can be assigned to the vext repository group.

[0098] For the sys repository group, for the remaining T code repositories out of the M code repositories (excluding those already assigned to the krn, hal, and vext repository groups), the electronic device will assign the identification information of the remaining T code repositories to the sys repository group as a set of code related to the system's core services.

[0099] Therefore, through the above partitioning logic, the electronic device can pre-divide the identification information of the M code repositories in the Manifest list into different repository groups according to the attribute information of the M code repositories.

[0100] It should be understood that during the above partitioning process, the identification information of the same code repository may simultaneously satisfy the partitioning conditions of at least two repository groups. For example, if a code repository's build configuration file 1 contains a preset hardware abstraction layer identifier field, and its build configuration file 2 contains a preset extended identifier field, then the identification information of this code repository will be partitioned into both the hal repository group and the vext repository group. Therefore, the sum of U, V, T, and W will be greater than or equal to M.

[0101] In the above technical solution, this application divides all code repositories into four independent repository groups based on the storage path and compilation configuration file of the code repository. This enables automatic classification of code repositories, which facilitates differentiated compilation and maintenance by group, thereby providing a separate code management strategy and avoiding the time-consuming problem caused by full compilation.

[0102] 103. In response to the target compilation instruction, determine the N target repository groups corresponding to the target compilation instruction from the L repository groups, where N is a positive integer greater than or equal to 1 and less than or equal to L.

[0103] Based on the obtained L repository groups, the electronic device can trigger a local compilation operation by receiving the target compilation instructions, and compile only the code files in the N target repository groups targeted by the target compilation instructions.

[0104] In one possible implementation, before determining the N target repository groups corresponding to the target compilation instructions from the L repository groups in response to the target compilation instructions, the code compilation method further includes: Generate group identifiers for L warehouse groups; and, In response to the target compilation directive, determine N target repository groups corresponding to the target compilation directive from L repository groups, including: The target compilation instructions are parsed to obtain the identification information of the target code repository corresponding to the target compilation instructions or the group identifier corresponding to the target compilation instructions; Match the identifier information of the target code repository with the identifier information of each code repository in the L repository groups, and determine the repository group to which the identifier information of the target code repository that is successfully matched belongs as N target repository groups; or, determine the repository group associated with the group identifier corresponding to the target compilation instruction as N target repository groups.

[0105] After the electronic device obtains the L divided repository groups, it can assign a unique group identifier to each repository group, and generate a repository group mapping table based on the group identifier of each repository group and the identifier information of the code repositories included in each repository group. The electronic device can also send the repository group mapping table to the client so that the client can store it.

[0106] Optionally, the group identifier for each warehouse group can be determined by random number generation, hash calculation, or generation by incrementing a preset sequence number, etc., and this application embodiment does not limit this. The form of the group identifier can be any of numbers, graphics, or letters, and this application embodiment does not limit this.

[0107] The triggering methods for target compilation instructions include, but are not limited to, the following: In the first method, developers input the identifier information of a specified code repository via the command line on the client and submit it. The client then generates the target compilation instructions based on the identifier information of the specified code repository and sends them to the electronic device.

[0108] The second method involves developers entering the group identifier of a specified repository group on the client via the command line and submitting it. The client then generates the target compilation instructions based on the specified repository group group identifier and sends them to the electronic device.

[0109] The third method involves developers selecting a specific code repository or its identifier in the client's visual interface and submitting the selection. The client then generates the target compilation instructions based on the selected code repository's identifier and sends them to the electronic device.

[0110] Fourthly, developers select a specific repository group or repository group identifier in the client's visual interface and submit. The client then generates target compilation instructions based on the selected repository group identifier and sends them to the electronic device.

[0111] Fifthly, after a developer modifies the source code or build configuration file of a certain code repository, they push the code changes to the Gerrit platform via Git push, generating a code change order. Upon receiving the code change order, the Gerrit platform parses the identifier information of the code repository involved in the change and, based on that identifier information, generates the target build instructions and sends them to the electronic device.

[0112] The first to fourth methods do not involve code changes, so the client can directly send the group identifier of the specified repository group or the identifier of the specified code repository to the electronic device. The fifth method involves code changes, which requires the Gerrit platform to parse the identifier of the code repository in the change order and send it to the electronic device.

[0113] Regardless of which method the target compilation instruction is triggered in, the electronic device can determine the N target repository groups corresponding to the target compilation instruction from the L repository groups based on the target compilation instruction.

[0114] Depending on the method of generating the target compilation instructions, after receiving the target compilation instructions, the electronic device can parse them to obtain the identifier information of the target code repository corresponding to the target compilation instructions, or to obtain the group identifier corresponding to the target compilation instructions. The target code repository is the code repository where the code specified or selected by the developer or the modified code is located, and the group identifier corresponding to the target compilation instructions is the unique group identifier of the repository group specified or selected by the developer.

[0115] Optionally, the number of target code repositories can be one or more, and this embodiment does not limit this. For example, when the target compilation instruction is triggered by specifying or selecting a certain repository group, the target code repository is all the code repositories within that repository group.

[0116] In one scenario, after the electronic device parses the target compilation instructions to obtain the identification information of the target code repository, the electronic device matches it with the identification information of the code repositories included in each repository group to determine the N target repository groups that match it, where N is a positive integer greater than or equal to 1.

[0117] In another scenario, when the electronic device parses the target compilation instructions to obtain the group identifier corresponding to the target compilation instructions, the electronic device matches the group identifier with the pre-stored repository group mapping table and determines the repository group associated with the group identifier as N target repository groups.

[0118] Thus, through the above process, the electronic device can determine the N target repository groups indicated by the target compilation instructions.

[0119] 104. Compile the target code files corresponding to the N target repository groups to obtain the compilation results of the target code files.

[0120] It should be understood that compilation is generally a step that needs to be performed after code files have been modified. In other words, when developers have not modified any code files, there is no need to perform a compilation operation, which can save computing resources and avoid repeated compilation.

[0121] Based on this, after obtaining N target repository groups, the electronic device can first determine whether the code files in the N target repository groups have been modified.

[0122] In one possible implementation, the target code files corresponding to the N target repository groups are compiled to obtain the compilation results of the target code files, including: For any target repository group among N target repository groups, determine whether the multiple candidate code files corresponding to the target repository group include modified code files; In the case of multiple candidate code files, including modified code files, the target code file is determined from the multiple candidate code files, and the target code file is compiled to obtain the compilation result of the target code file.

[0123] Specifically, for any one of the N target repository groups, the electronic device first determines whether the multiple candidate code files corresponding to that target repository group exist or include modified code files. The multiple candidate code files corresponding to the target repository group are all the code files corresponding to the identification information of all code repositories included in the target repository group.

[0124] When multiple candidate code files include modified code files (i.e., code files whose content has been changed this time), it indicates that there are indeed code files in the target repository group that need to be recompiled. The electronic device can then further determine the target code file that needs to be compiled this time from the multiple candidate code files, and compile the target code file to obtain the compilation result of the target code file.

[0125] The connection and difference between the target code file and the modified code file lies in the fact that the modified code file is the code file that was changed in this instance, that is, the code file that the developers directly modified in this instance. The target code file is the code file that needs to be compiled in this instance, based on the modified code file.

[0126] Conversely, if multiple candidate code files do not include the modified code files, it means that the developers have not modified any code files within the target repository group, and no compilation operation is required for the target repository group. This can significantly save code compilation time and improve code compilation efficiency.

[0127] In the above technical solution, the modification status of each candidate code file in the target repository group is checked before the code compilation operation is performed. The compilation is only performed when there are modified code files in the target repository group. This can effectively filter out invalid compilation tasks in scenarios where there is no code modification and reduce the waste of resources caused by unnecessary compilation operations.

[0128] The following describes the specific process for determining whether multiple candidate code files corresponding to a target repository group include modified code files.

[0129] In one possible implementation, determining whether multiple candidate code files corresponding to the target repository group include modified code files includes: For any candidate code file among multiple candidate code files, obtain the current hash value and the historical hash value at the end of the last compilation. If the current hash value is the same as the historical hash value, the candidate code files are determined to exclude the modified code files; If the current hash value differs from the historical hash value, multiple candidate code files are identified, including modified code files, and the candidate code files are identified as modified code files.

[0130] It should be understood that the hash value of a code file can serve as a unique identifier for the code file. It is generated by converting the content of a code file of arbitrary length into a fixed-length string using a specific mathematical algorithm. Optionally, the specific mathematical algorithm includes Secure Hash Algorithm (SHA) 256, Message Digest Algorithm (MDA) 5, etc., and this application embodiment does not limit the specific algorithm used.

[0131] Therefore, whenever the content of a code file changes (e.g., adding lines of code, adding spaces, or modifying comments), the hash value of the corresponding code file will change. Conversely, if the content of the code file remains completely identical, the hash value of the code file will not change.

[0132] For any one of the multiple candidate code files, after receiving the target compilation instructions, the electronic device can pull the latest code files (i.e., multiple candidate code files) stored in each code repository from the remote Git repository and store them locally, based on the identification information of each code repository in the target repository group.

[0133] Based on this, the electronic device can perform hash calculations on each candidate code file separately to obtain the current hash value of each candidate code file. At the same time, the electronic device can also retrieve the historical hash values ​​of each code file saved during the last compilation.

[0134] For any candidate code file, the electronic device can compare the current hash value of the candidate code file with the historical hash value at the end of the last compilation.

[0135] When the current hash value of a candidate code file is the same as the historical hash value at the end of the last compilation, it means that the candidate code file was not actually modified when the target compilation instruction was triggered. For example, a developer might specify a code file via command line or select it in a visual interface, but the code file itself has not been modified. In this case, the electronic device determines that the modified code file is not included among the multiple candidate code files.

[0136] When the current hash value of a candidate code file differs from the historical hash value at the end of the last compilation, it indicates that the candidate code file was actually modified when the target compilation instruction was triggered. For example, a developer might modify a line of code in a code file and submit it to the Gerrit platform. In this case, the electronic device determines that multiple candidate code files include the modified code file.

[0137] In the above technical solution, this application determines whether the candidate code file has been modified by comparing the hash value of the code file. It can accurately identify whether the code file has changed content compared to the end of the previous compilation, effectively filter out the code file that really needs to be compiled, and improve the accuracy and reliability of compilation.

[0138] When multiple candidate code files are identified, including modified code files, the electronic device further determines the target code file from the multiple candidate code files as follows.

[0139] One possible implementation involves determining the target code file from multiple candidate code files, including: Retrieve the global dependency tree corresponding to the target repository group. The global dependency tree is used to represent the dependency relationships between multiple candidate code files. Based on the global dependency tree corresponding to the target repository group, identify at least one candidate code file that has a dependency relationship with the modified code file among multiple candidate code files; The modified code file and at least one candidate code file are identified as the target code file.

[0140] The aforementioned target code file specifically includes the modified code file and at least one candidate code file among multiple candidate code files that has a strong dependency relationship with the modified code file.

[0141] It should be understood that strong references typically exist between code files in the Android build system. For example, if build module A is linked by build module B, and the code files of build module A are modified, the linking result of build module B will become invalid. If build module B is not recompiled, the final system image may experience crashes or other problems.

[0142] Based on this, the electronic device can first traverse all compilation configuration files and all candidate code files within the target repository group, extract the explicit library dependencies between compilation modules and the implicit file dependencies formed by include / import within the candidate code files, and generate a tree-like association data of the target repository group, namely the global dependency tree, with candidate code files as nodes and strong dependencies between files as directed edges.

[0143] Based on a global dependency tree, electronic devices can search for candidate code files corresponding to downstream nodes and upstream nodes of the modified code file's corresponding node, identifying each downstream and upstream candidate code file as at least one candidate code file. Specifically, the candidate code files corresponding to downstream nodes of the modified code file's corresponding node are all candidate code files that depend on the modified code file, while the candidate code files corresponding to upstream nodes of the modified code file's corresponding node are candidate code files that the modified code file depends on. These two types of candidate code files represent those with a strong dependency relationship with the modified code file.

[0144] After identifying at least one candidate code file, the electronic device can identify the modified code file and at least one candidate code file as the target code file.

[0145] Optionally, the number of modified code files can be one or more. When there is only one modified code file, the target code file is at least one candidate code file that the modified code file strongly depends on. When there are multiple modified code files, the target code file is at least one candidate code file that each modified code file strongly depends on.

[0146] In the above technical solution, when determining the target code file, this application identifies the dependency relationship between each code file in the target repository group through the global dependency tree of the target repository group, thereby accurately identifying the candidate code file in the target repository group that has a strong dependency relationship with the modified code file and incorporating it into the target code file. This can avoid compilation errors caused by missing dependencies and improve the success rate of this compilation.

[0147] After the target code file is identified, the electronic device can perform compilation operations on the target code file in the target repository group and retain the previous compilation results of the code files in the target repository group other than the target code file.

[0148] After obtaining the compilation result of the target code file, the electronic device can further verify whether the compilation result of the target code file meets the preset compilation specifications and quality standards, such as whether there are undefined symbols or interface call errors. If the verification passes, the compilation result is updated to the local cache; otherwise, the developer is prompted to fix the corresponding problem and modify the code until the compilation result meets the preset compilation specifications and quality standards.

[0149] After obtaining the compilation results of the target code file, the electronic device can store the compilation results in a local temporary directory for use when generating a system image later.

[0150] Therefore, the above is the overall implementation process of the separate compilation strategy provided in the embodiments of this application.

[0151] To facilitate understanding of the overall implementation scheme of the embodiments of this application, the following will further illustrate... Figure 3 The overall implementation process of the above method will be introduced.

[0152] Figure 3 This is a schematic flowchart of another code compilation method provided in the embodiments of this application.

[0153] For example, such as Figure 3 As shown, the code compilation method 300 includes the following steps 301 to 312.

[0154] 301. Obtain the target code repository list. The target code repository list includes the identification information of M code repositories. The M code repositories are used to store the various code files to be compiled.

[0155] 302, retrieve attribute information for M code repositories.

[0156] 303. Generate a kernel repository group based on the identification information of U code repositories out of M code repositories.

[0157] 304. Generate a hardware abstraction layer repository group based on the identification information of V code repositories out of M code repositories.

[0158] 305. Generate an extended repository group based on the identification information of W code repositories out of M code repositories.

[0159] 306. Generate a system repository group based on the identification information of T code repositories out of M code repositories.

[0160] 307, Generate group identifiers for L warehouse groups.

[0161] 308. Parse the target compilation instructions to obtain the identifier information of the target code repository corresponding to the target compilation instructions or the group identifier corresponding to the target compilation instructions.

[0162] 309. Match the identifier information of the target code repository with the identifier information of each code repository in the L repository groups, and determine the repository group to which the identifier information of the target code repository belongs after a successful match as N target repository groups; or, determine the repository group associated with the group identifier corresponding to the target compilation instruction as N target repository groups.

[0163] 310. Determine whether multiple candidate code files in any target repository group include modified code files.

[0164] If the candidate code files in any target repository group do not include the modified code files, proceed to step 311; If multiple candidate code files, including modified code files, are grouped in any target repository, proceed to step 312.

[0165] 311, End of compilation process.

[0166] 312. Determine the target code file from multiple candidate code files, compile the target code file, and obtain the compilation result of the target code file.

[0167] Steps 301 to 312 in the above code compilation method 300 have the same inventive concept as steps 101 and 104 in the code compilation method 100. For details, please refer to the description of the aforementioned method 100, which will not be repeated here.

[0168] In summary, this application provides a code compilation method. The specific implementation process of this method is as follows: First, a list of target code repositories for this compilation is obtained. This list includes identification information for M code repositories, which store the code files to be compiled. Further, the M code repositories are categorized into L repository groups, each including identification information for at least one code repository. This categorization allows the code repositories to be pre-divided into multiple independent repository groups according to functional modules. The code files within each repository group are relatively independent, providing a foundation for subsequent separate compilation. Finally, upon receiving a target compilation instruction, N target repository groups are determined from the L repository groups, and the target code files in these N target repository groups are compiled. This method compiles only the code files of a partial repository group within the L repository groups, without requiring a full compilation of all code files in the L repository groups. This enables partial or on-demand compilation of code files, significantly reducing compilation time and resource consumption, and improving compilation efficiency.

[0169] Figure 4 This is a schematic diagram of the structure of a code compilation device provided in an embodiment of this application.

[0170] For example, such as Figure 4 As shown, the code compilation device 400 includes: The acquisition module 401 is used to acquire a list of target code repositories, which includes the identification information of M code repositories. These M code repositories are used to store the code files to be compiled, where M is a positive integer greater than 1. The determining module 402 is used to classify the M code repositories to obtain L repository groups of different categories, each repository group including identification information of at least one code repository, where L is a positive integer greater than 1; the determining module 402 is also used to determine N target repository groups corresponding to the target compilation instruction from the L repository groups in response to the target compilation instruction, where N is a positive integer greater than or equal to 1 and less than or equal to L; and, The compilation module 403 is used to compile the target code files corresponding to the N target repository groups to obtain the compilation results of the target code files.

[0171] In one possible implementation, the determining module 402 is specifically used to: obtain the attribute information of the M code repositories; classify the M code repositories according to the attribute information of the M code repositories to obtain the L repository groups.

[0172] In one possible implementation, the L repository groups include a kernel repository group, a hardware abstraction layer repository group, an extension repository group, and a system repository group. The attribute information includes storage paths and build configuration files. The determining module 402 is further configured to: generate the kernel repository group based on the identification information of U code repositories among the M code repositories, where U is a positive integer greater than or equal to 1 and less than or equal to M, and the storage paths of the U code repositories are all preset kernel paths; generate the hardware abstraction layer repository group based on the identification information of V code repositories among the M code repositories, where V is a positive integer greater than or equal to 1 and less than or equal to M, and the storage paths of the V code repositories are all preset kernel paths; and generate the hardware abstraction layer repository group based on the identification information of V code repositories among the M code repositories. The compilation configuration file includes a preset hardware abstraction layer identifier field; based on the identifier information of W code repositories out of the M code repositories, the extended repository group is generated, where W is a positive integer greater than or equal to 1 and less than or equal to M, and the compilation configuration file of the W code repositories includes a preset extended identifier field; based on the identifier information of T code repositories out of the M code repositories, the system repository group is generated, where T is a positive integer greater than or equal to 1 and less than or equal to M, and the T code repositories are the code repositories other than the U code repositories, the V code repositories, and the W code repositories out of the M code repositories, and the sum of U, V, T, and W is greater than or equal to M.

[0173] In one possible implementation, before determining the N target repository groups corresponding to the target compilation instruction from the L repository groups in response to the target compilation instruction, the determining module 402 is further configured to: generate group identifiers for the L repository groups; and the determining module 402 is further configured to: parse the target compilation instruction to obtain the identifier information of the target code repository corresponding to the target compilation instruction or the group identifier corresponding to the target compilation instruction; match the identifier information of the target code repository with the identifier information of each code repository in the L repository groups, and determine the repository group to which the identifier information of the successfully matched target code repository belongs as the N target repository groups; or, determine the repository group associated with the group identifier corresponding to the target compilation instruction as the N target repository groups.

[0174] In one possible implementation, the compilation module 403 is specifically used to: for any target repository group among the N target repository groups, determine whether the multiple candidate code files corresponding to the target repository group include the modified code file; if the multiple candidate code files include the modified code file, determine the target code file from the multiple candidate code files, and compile the target code file to obtain the compilation result of the target code file.

[0175] In one possible implementation, the compilation module 403 is further configured to: for any candidate code file among the plurality of candidate code files, obtain the current hash value of the candidate code file and the historical hash value at the end of the last compilation; if the current hash value is the same as the historical hash value, determine that the plurality of candidate code files does not include the modified code file; if the current hash value is different from the historical hash value, determine that the plurality of candidate code files includes the modified code file, and identify the candidate code file as the modified code file.

[0176] In one possible implementation, the compilation module 403 is further configured to: obtain the global dependency tree corresponding to the target repository group, the global dependency tree being used to represent the dependency relationships between the multiple candidate code files; determine at least one candidate code file among the multiple candidate code files that has a dependency relationship with the modified code file based on the global dependency tree corresponding to the target repository group; and determine the modified code file and the at least one candidate code file as the target code file.

[0177] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0178] For example, such as Figure 5As shown, the electronic device 500 includes a memory 501 and a processor 502. The memory 501 stores executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to perform the above-described code compilation method.

[0179] This embodiment can divide the electronic device into functional modules according to the above method example. For example, each module can correspond to a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0180] When each functional module is divided according to its corresponding function, the electronic device may include: an acquisition module, a determination module, and a compilation module, etc. It should be noted that all relevant content of each step involved in the above code compilation method embodiment can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0181] The electronic device provided in this embodiment is used to execute the above-described code compilation method, and therefore can achieve the same effect as the above-described implementation method.

[0182] When using integrated units, the electronic device may include a processing module and a storage module. The processing module is used to control and manage the operation of the electronic device. The storage module is used to support the execution of relevant program code and data by the electronic device.

[0183] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0184] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the code compilation method in the above embodiment.

[0185] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the code compilation method described in the above embodiment.

[0186] In addition, the electronic device provided in the embodiments of this application may specifically be a chip, component or module. The electronic device may include a connected processor and a memory. The memory is used to store instructions. When the electronic device is running, the processor may call and execute the instructions to make the chip execute the code compilation method in the above embodiments.

[0187] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0188] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0189] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0190] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A code compilation method, characterized in that, The code compilation method includes: Obtain a list of target code repositories, which includes identification information for M code repositories. The M code repositories are used to store the code files to be compiled, where M is a positive integer greater than 1. The M code repositories are classified to obtain L repositories of different categories. Each repository group includes the identification information of at least one code repository, where L is a positive integer greater than 1. In response to the target compilation instruction, N target repository groups corresponding to the target compilation instruction are determined from the L repository groups, where N is a positive integer greater than or equal to 1 and less than or equal to L; The target code files corresponding to the N target repository groups are compiled to obtain the compilation results of the target code files.

2. The code compilation method according to claim 1, characterized in that, The process of classifying the M code repositories to obtain L repositories grouped into different categories includes: Obtain the attribute information of the M code repositories; Based on the attribute information of the M code repositories, the M code repositories are classified to obtain the L repository groups.

3. The code compilation method according to claim 2, characterized in that, The L repository groups include a kernel repository group, a hardware abstraction layer repository group, an extension repository group, and a system repository group. The attribute information includes storage paths and build configuration files. The L repository groups are obtained by classifying the M code repositories based on their attribute information, including: The kernel repository group is generated based on the identification information of U code repositories among the M code repositories, where U is a positive integer greater than or equal to 1 and less than or equal to M, and the storage paths of the U code repositories are all preset kernel paths; The hardware abstraction layer repository group is generated based on the identification information of V code repositories among the M code repositories, where V is a positive integer greater than or equal to 1 and less than or equal to M, and the compilation configuration files of the V code repositories include a preset hardware abstraction layer identification field. The extended repository group is generated based on the identification information of W code repositories out of the M code repositories, where W is a positive integer greater than or equal to 1 and less than or equal to M, and the compilation configuration files of the W code repositories include a preset extended identifier field; The system repository group is generated based on the identification information of T code repositories out of the M code repositories, where T is a positive integer greater than or equal to 1 and less than or equal to M, and the T code repositories are the code repositories other than the U code repositories, the V code repositories and the W code repositories out of the M code repositories, and the sum of U, V, T and W is greater than or equal to M.

4. The code compilation method according to claim 1, characterized in that, Before determining the N target repository groups corresponding to the target compilation instruction from the L repository groups in response to the target compilation instruction, the code compilation method further includes: Generate group identifiers for the L warehouse groups; and, The step of determining N target repository groups corresponding to the target compilation instruction from the L repository groups in response to the target compilation instruction includes: The target compilation instructions are parsed to obtain the identification information of the target code repository corresponding to the target compilation instructions or the group identifier corresponding to the target compilation instructions; The identification information of the target code repository is matched with the identification information of each code repository in the L repository groups, and the repository group to which the identification information of the target code repository that is successfully matched is determined as the N target repository groups; or, the repository group associated with the group identifier corresponding to the target compilation instruction is determined as the N target repository groups.

5. The code compilation method according to claim 4, characterized in that, The process of compiling the target code files corresponding to the N target repository groups to obtain the compilation results of the target code files includes: For any target repository group among the N target repository groups, determine whether the multiple candidate code files corresponding to the target repository group include modified code files; If the multiple candidate code files include the modified code file, the target code file is determined from the multiple candidate code files, and the target code file is compiled to obtain the compilation result of the target code file.

6. The code compilation method according to claim 5, characterized in that, Determining whether the multiple candidate code files corresponding to the target repository group include modified code files includes: For any candidate code file among the plurality of candidate code files, obtain the current hash value and the historical hash value at the end of the last compilation of the candidate code file; If the current hash value is the same as the historical hash value, it is determined that the modified code file is not included among the plurality of candidate code files; If the current hash value is different from the historical hash value, the plurality of candidate code files are determined to include the modified code file, and the candidate code file is identified as the modified code file.

7. The code compilation method according to claim 5 or 6, characterized in that, The step of determining the target code file from the plurality of candidate code files includes: Obtain the global dependency tree corresponding to the target repository group, whereby the global dependency tree represents the dependency relationships between the multiple candidate code files; Based on the global dependency tree corresponding to the target repository group, determine at least one candidate code file among the multiple candidate code files that has a dependency relationship with the modified code file; The modified code file and the at least one candidate code file are identified as the target code file.

8. A code compilation apparatus, characterized in that, The code compilation device includes: The acquisition module is used to acquire a list of target code repositories, which includes identification information of M code repositories. The M code repositories are used to store various code files to be compiled, where M is a positive integer greater than 1. The determining module is configured to classify the M code repositories to obtain L repository groups of different categories, each repository group including identification information of at least one code repository, where L is a positive integer greater than 1; the determining module is further configured to, in response to a target compilation instruction, determine N target repository groups corresponding to the target compilation instruction from the L repository groups, where N is a positive integer greater than or equal to 1 and less than or equal to L; and, The compilation module is used to compile the target code files corresponding to the N target repository groups to obtain the compilation results of the target code files.

9. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; and, A processor for calling and running the executable program code from the memory, causing the electronic device to perform the code compilation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the code compilation method as described in any one of claims 1 to 7.

Images