Compilation method and related device

Abstract

A compilation method and a related device, by means of which full compilation can be avoided to the greatest extent in the scenario of first instance of compilation of a code project, thereby reducing the time cost of compilation. For example, a server comprises a code project and first dependency relationships, wherein the code project comprises N modules, and none of the N modules has been compiled. A terminal device sends a first compilation instruction to the server, wherein the first compilation instruction is used for instructing the compilation of a first module in the code project; on the basis of the first module and the first dependency relationships, the server determines from the code project a second module having a dependency relationship with the first module, wherein the first dependency relationships are used for describing dependency relationships between the N modules; and the server compiles the first module and the second module.

Description

A compilation method and related equipment

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510239372.8, filed on February 28, 2025, entitled "A Compilation Method and Related Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of terminal technology, and in particular to a compilation method and related equipment. Background Technology

[0004] In software development, after programmers write the source code files, they need to go through a compilation process to convert the source code files into files that the machine can run. Generally, a code project contains multiple source code files, and the code project needs to be fully compiled on the first compilation. However, full compilation is time-consuming, especially for large code projects, where the large number of source code files makes full compilation too time-consuming and affects the software development schedule. Summary of the Invention

[0005] This application provides a compilation method and related equipment that can reduce compilation time and costs in the first compilation of a code project, thereby helping to improve software development progress.

[0006] Firstly, a compilation method is provided, applied to a system including a terminal device and a server. The server includes a code project comprising N modules, where N is a positive integer, and none of the N modules have been compiled. The method includes: the terminal device sending a first compilation instruction to the server, the first compilation instruction instructing the compilation of a first module in the code project; the server determining a second module in the code project that has a dependency relationship with the first module based on the first module and a first dependency relationship, the first dependency relationship describing the dependency relationships among the N modules; or, the first dependency relationship describing the dependency relationships between the first module and other modules among the N modules excluding the first module; and the server compiling the first module and the second module.

[0007] It should be noted that currently, code projects require a full compilation upon initial compilation. In this embodiment, the code project is not compiled entirely upon initial compilation. Instead, after identifying the first module to be compiled, the first module and any related second modules are compiled together. Modules not related to the first module do not need to be compiled. This approach reduces compilation time during the initial compilation and, by compiling dependent modules together, avoids compilation errors and ensures accuracy.

[0008] A requirement / idea (also known as a software project) often requires multiple modules to support it. Each module may include one or more source code files, and the collection of these modules is called a "code project." It should be understood that the more complex the functionality of a software project, the more modules and source code files it contains, resulting in a larger code project. The technical solution provided in this application's embodiments allows for partial compilation of large code projects instead of a full compilation on the first run, thereby reducing compilation time and costs and helping to improve the development progress of the software project.

[0009] In this embodiment of the application, the first dependency relationship may be the total dependency relationship among N modules, or it may be the dependency relationship between the first module and other modules (e.g., the type declaration located in the script file of the first module).

[0010] In one possible design, the server compiles both the first and second modules, including: the server compiles the source code files in both modules. If the first module contains multiple source code files, the server compiles the first module, i.e., all source code files in the first module are compiled. If the second module contains multiple source code files, the server compiles the second module, i.e., all source code files in the second module are compiled.

[0011] In one possible design, the method further includes: the terminal device modifying the first module; the terminal device sending a second compilation instruction to the server, the second compilation instruction being used to instruct the first module to be recompiled; the server determining a third module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; and the server recompiling the first module and the third module.

[0012] It should be noted that currently, if source code files in a code project are modified, incremental compilation is required. Incremental compilation utilizes the intermediate artifacts (i.e., object files) generated during the initial compilation process and the dependencies between these object files. Therefore, the intermediate artifacts (i.e., object files) and their dependencies must be stored. If the code project is large, there will be many intermediate artifacts, which consumes a significant amount of storage space. In this embodiment, after the source code files in the first module are modified, incremental compilation is not used. Instead, the first module and the third module that has dependencies on the first module are re-entered into the compilation system for compilation. Therefore, there is no need to store the intermediate artifacts generated during the initial compilation process, saving storage space. Moreover, since all modules with dependencies are recompiled, compilation errors can be avoided, resulting in higher accuracy.

[0013] In one possible design, the terminal device modifies the first module by modifying the source code file in the first module.

[0014] In one possible design, the method further includes: the terminal device adding a source code file to the first module; the terminal device sending a third compilation instruction to the server, the third compilation instruction being used to instruct the first module to be recompiled; the server determining a fourth module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; and the server recompiling the first module and the fourth module.

[0015] It should be noted that currently, if a new source code file is added to the code project, a full compilation is required. In this embodiment, after adding a new source code file to the first module, a full compilation is not required. Only the first module and the fourth module that depends on the first module need to be recompiled, which helps to reduce the time cost of recompilation.

[0016] In one possible design, the method further includes: the server receiving a fifth module sent by the terminal device, the fifth module being a newly added module in the code project; and the server adding a dependency relationship between the newly added module and the N modules in the first dependency relationship based on the newly added module.

[0017] Therefore, in this embodiment of the application, after adding a new module to the code project, the first dependency relationship between modules can be updated. Because of the update of the first dependency relationship, modules with dependencies can be accurately identified, avoiding omissions of modules.

[0018] It should be noted that currently, when a new module is added to a code project, a full compilation is required to compile the new module. In this embodiment, when a new module is added to a code project, a full compilation is not required. Instead, based on the new module and the updated first dependency relationship, the modules that have dependencies on the new module are determined, and the new module and its dependent modules are compiled. Modules that do not have dependencies on the new module do not need to be compiled, which helps reduce compilation time costs.

[0019] In one possible design, before the server determines the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, the method further includes: the server receiving a script file of the first module sent by the terminal device, the script file including a declaration of the dependency relationship between the first module and other modules in the code project other than the first module; and the server generating the first dependency relationship based on the script file of the first module.

[0020] Therefore, in this embodiment of the application, the server can generate a first dependency relationship. Through the first dependency relationship, the modules with dependencies can be identified, thereby achieving local compilation and reducing compilation time.

[0021] In one possible design, the server determines a second module in the code project that has a dependency on the first module based on the first module and the first dependency, including: the server determines a second module in the code project that has a dependency on the first module based on the first module and the first dependency, and a sixth module in the code project that has a dependency on the second module; the server compiles the first module and the second module, including: the server compiles the first module, the second module and the sixth module.

[0022] Therefore, in this embodiment, to compile the first module in the code project, the first module and all modules that the first module directly and indirectly depends on are compiled for the first time. For example, if the first module directly depends on the second module, and the second module directly depends on the sixth module (meaning the first module indirectly depends on the sixth module), then the first module, the second module, and the sixth module are all compiled for the first time. This method identifies all modules that depend on the first module, preventing compilation errors caused by missing modules.

[0023] In one possible design, before compiling the first module for the first time, the type of the first module can be determined. If it is of type 1 (e.g., a dynamic library file or an executable file), it means that the first module is an independent module, and there is no need to search for modules that have dependencies on the first module. If it is of type 2 (e.g., a static library file), then modules that have dependencies on the first module are searched. In this way, invalid searches can be avoided to some extent, improving efficiency.

[0024] In one possible design, the script file of the first module includes a type declaration, where the type includes at least one of a static library file, a dynamic library file, or an executable file. Therefore, in this embodiment, the script file can declare various types such as static library files, dynamic library files, or executable files. By determining the type of the first module, it is possible to determine whether it is necessary to search for modules that have a dependency on the first module, thus avoiding invalid searches.

[0025] In one possible design, the first module is a static library file.

[0026] In one possible design, determining the second module in the code project that has a dependency on the first module includes: determining that the first module depends on the second module. For example, the first module calls the second module through an interface.

[0027] In one possible design, determining the second module in the code project that has a dependency on the first module includes: determining that the second module depends on the first module. For example, the second module calls the first module through an interface.

[0028] In one possible design, before the server compiles the first module and the second module, the method further includes: the terminal device receiving a prompt message sent by the server, the prompt message indicating whether to compile the second module; and the terminal device sending a confirmation compilation instruction to the server in response to a user confirmation operation.

[0029] Therefore, in this embodiment of the application, it is possible to avoid compiling the second module that is dependent on the first module without the knowledge of the user (e.g., the programmer), which helps to improve accuracy.

[0030] Secondly, a compilation method is also provided, applied to a terminal device. The method includes: the terminal device determining a first module, the first module being at least one of N modules included in a code project, where N is a positive integer, and none of the N modules have been compiled, and the code project is located on a server; the terminal device sending a first compilation instruction to the server, the first compilation instruction being used to trigger the server to determine a second module in the code project that has a dependency relationship with the first module based on the first module and a first dependency relationship, and to compile the first module and the second module, wherein the first dependency relationship is used to describe the dependency relationship between the N modules, or the first dependency relationship is used to describe the dependency relationship between the first module and other modules among the N modules besides the first module.

[0031] In one possible design, compiling the first module and the second module includes compiling the source code files in the first module and the second module. If the first module includes multiple source code files, compiling the first module means compiling all the source code files in the first module. If the second module includes multiple source code files, compiling the second module means compiling all the source code files in the second module.

[0032] In one possible design, the method further includes: the terminal device modifying the first module; the terminal device sending a second compilation instruction to the server, the second compilation instruction being used to trigger the server to determine a third module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, and to recompile the first module and the third module.

[0033] In one possible design, the method further includes: the terminal device adding a source code file to the first module; the terminal device sending a third compilation instruction to the server, the third compilation instruction being used to trigger the server to determine a fourth module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, and to recompile the first module and the fourth module.

[0034] In one possible design, the method further includes: the terminal device sending a fifth module to the server, the fifth module being a newly added module in the code project, and the server being used to add a dependency relationship between the newly added module and the N modules in the first dependency relationship based on the newly added module.

[0035] In one possible design, the method further includes: the terminal device sending a script file of the first module to the server, the script file including a declaration of dependencies between the first module and other modules in the code project besides the first module, so that the server generates the first dependency based on the script file of the first module.

[0036] In one possible design, the script file of the first module includes a type declaration, the type of which includes at least one of a static library file, a dynamic library file, or an executable file.

[0037] In one possible design, the first module is a static library file.

[0038] In one possible design, the first module and the second module have a dependency relationship, including: the first module depends on the second module.

[0039] In one possible design, the first module and the second module have a dependency relationship, including: the second module depends on the first module.

[0040] In one possible design, the method further includes: the terminal device receiving a prompt message sent by the server, the prompt message being used to prompt whether to compile the second module; and the terminal device, in response to a user confirmation operation, sending a confirmation compilation instruction to the server.

[0041] Thirdly, a compilation method is also provided, applied to a server, the server including a code project comprising N modules, where N is a positive integer, and none of the N modules have been compiled. The method includes: the server receiving a first compilation instruction sent by a terminal device, the first compilation instruction instructing the compilation of a first module in the code project; the server determining a second module in the code project that has a dependency relationship with the first module based on the first module and a first dependency relationship, the first dependency relationship describing the dependency relationship between the N modules, or, the first dependency relationship describing the dependency relationship between the first module and other modules among the N modules excluding the first module; and the server compiling the first module and the second module.

[0042] In one possible design, the server compiles the first module and the second module, including: the server compiles the source code files in the first module and the second module. If the first module includes multiple source code files, the first module is compiled, that is, all source code files in the first module are compiled. If the second module includes multiple source code files, the second module is compiled, that is, all source code files in the second module are compiled.

[0043] In one possible design, the method further includes: the server determining that the first module has been modified; the server receiving a second compilation instruction sent by the terminal device, the second compilation instruction being used to instruct the first module to be recompiled; the server determining a third module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; and the server recompiling the first module and the third module.

[0044] In one possible design, the method further includes: the server determining a newly added source code file within the first module; the server receiving a third compilation instruction sent by the terminal device, the third compilation instruction being used to instruct the first module to be recompiled; the server determining a fourth module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; and the server recompiling the first module and the fourth module.

[0045] In one possible design, the method further includes: the server receiving a fifth module sent by the terminal device, the fifth module being a newly added module in the code project; and the server adding a dependency relationship between the newly added module and the N modules in the first dependency relationship based on the newly added module.

[0046] In one possible design, before the server determines the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, the method further includes: the server receiving a script file of the first module sent by the terminal device, the script file including a declaration of the dependency relationship between the first module and other modules in the code project other than the first module; the server generating the first dependency relationship based on the script file of the first module.

[0047] In one possible design, the server determines a second module in the code project that has a dependency on the first module based on the first module and the first dependency, including: the server determines a second module that has a dependency on the first module and a sixth module that has a dependency on the second module; the server compiles the first module and the second module, including: the server compiles the first module, the second module and the sixth module.

[0048] In one possible design, the script file of the first module includes a type declaration, the type of which includes at least one of a static library file, a dynamic library file, or an executable file.

[0049] In one possible design, the first module is a static library file.

[0050] In one possible design, determining the second module in the code project that has a dependency relationship with the first module includes: determining that the first module depends on the second module.

[0051] In one possible design, determining the second module in the code project that has a dependency relationship with the first module includes: determining that the second module depends on the first module.

[0052] In one possible design, before the server compiles the first module and the second module, the method further includes: the server sending a prompt message to the terminal device, the prompt message indicating whether to compile the second module; and the server receiving a confirmation compilation instruction sent by the terminal device.

[0053] Fourthly, a system is also provided, comprising:

[0054] A terminal device for performing the method as provided in the second aspect above;

[0055] The server is used to execute the methods provided in the third aspect above.

[0056] Fifthly, a terminal device is also provided for performing the method as described in the second aspect above.

[0057] Sixthly, a server is also provided for performing the methods provided in the third aspect above.

[0058] In a seventh aspect, a computer-readable storage medium is also provided for storing a computer program that, when run on a computer, causes the computer to perform the methods provided in the first, second, or third aspects described above.

[0059] Eighthly, a computer program product is also provided, comprising a computer program that, when run on a computer, causes the computer to perform the methods provided in the first, second, or third aspects described above.

[0060] Ninthly, a chip is also provided for performing the methods provided in the first, second, or third aspects described above.

[0061] In a tenth aspect, a chip system is also provided, comprising:

[0062] A first chip is used to perform the method provided in the second aspect above;

[0063] The second chip is used to perform the method provided in the third aspect above.

[0064] For the technical effects that can be achieved in the second to tenth aspects mentioned above, please refer to the description of the technical effects that can be achieved by the corresponding design schemes in the first aspect mentioned above. This application will not repeat them here. Attached Figure Description

[0065] Figure 1 is a schematic diagram of a software development process provided in an embodiment of this application;

[0066] Figure 2 is a schematic diagram of a compilation system provided in an embodiment of this application;

[0067] Figures 3A to 3D are schematic diagrams illustrating the compilation of a code project provided in an embodiment of this application using a compilation system;

[0068] Figure 4 is a schematic diagram of the compilation architecture provided in an embodiment of this application;

[0069] Figures 5A to 5D are schematic diagrams illustrating the process of determining the dependencies between modules within a code project according to an embodiment of this application;

[0070] Figures 6A and 6B are schematic diagrams of a partial compilation process of a code project provided in an embodiment of this application;

[0071] Figures 7A to 7C are schematic diagrams illustrating the determination of other modules that are dependent on the first module according to an embodiment of this application;

[0072] Figures 8A to 8C are another schematic diagram illustrating the determination of other modules that are dependent on the first module according to an embodiment of this application;

[0073] Figures 9A and 9B are schematic diagrams illustrating the compilation process in the case of modified / added source files according to an embodiment of this application;

[0074] Figure 10 is a schematic diagram of a newly added module provided in an embodiment of this application;

[0075] Figure 11 is a schematic diagram of a communication system provided in an embodiment of this application;

[0076] Figure 12 is a flowchart illustrating a compilation method provided in an embodiment of this application;

[0077] Figure 13 is a schematic diagram of a terminal device provided in an embodiment of this application;

[0078] Figure 14 is a schematic diagram of an electronic device provided in an embodiment of this application;

[0079] Figure 15 is another schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0080] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0081] The embodiments of this application involve at least one, including one or more; where "multiple" means two or more. Furthermore, it should be understood that in the description of this specification, terms such as "first," "second," and "third" are used only for descriptive purposes and should not be construed as indicating relative importance or order. For example, "first module" and "second module" do not represent the degree of importance or order between them, but are merely for descriptive distinction. In the embodiments of this application, "and / or" merely describes an association relationship, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0082] The directional terms mentioned in the embodiments of this application, such as "up", "down", "left", "right", "inner", and "outer", are only for reference to the directions in the accompanying drawings. Therefore, the directional terms used are for better and clearer explanation and understanding of the embodiments of this application, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0083] References to "one embodiment," "in some examples," or "some embodiments" as described in the embodiments of this application mean that one or more embodiments of this specification include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in some examples," "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0084] The technical solutions provided in this application can be applied to software development scenarios. For example, Figure 1 is a schematic diagram of a software development process provided in an embodiment of this application. As shown in Figure 1, after understanding the requirements / ideas, the programmer writes source code files (hereinafter referred to as source files) based on the requirements / ideas. Then, the source code files are compiled into machine-executable products. This process is the software development process. The following explains the terms involved in Figure 1.

[0085] (1) Source File. The program code written by a programmer is called "source code." Source code is stored in the form of a file, which is called a "source code file," or simply "source file." The process of a programmer writing a source file can be called the programming process. It should be understood that each programmer may use different programming languages, such as Java, C, C++, etc., so the source code contained in a source file can be code written in various programming languages. It should be noted that source files cannot be directly run by a machine; they need to be converted into files that the machine can run.

[0086] (2) Product. The source file, after conversion, becomes a machine-executable file; this file is called the "product." One source file can correspond to one product. The product is a machine-executable file, such as a library file or an executable file. For example, a library file can include: static library files (e.g., .lib files), dynamic library files (e.g., .dll files), database files (e.g., .db files, .mdb files, etc.) or other library files. For executable files, there are no restrictions, such as .exe files, .com files, .bat files, etc.

[0087] (3) The process of converting source files into output files is also called the "compilation process". Currently, the compilation process can be implemented through a compilation system. The compilation system will be described below.

[0088] For example, Figure 2 is a schematic diagram of a compilation system provided in an embodiment of this application. As shown in Figure 2, the compilation system includes a compilation module, an assembly module, and a linking module. The compilation module is used to compile source files, which can be understood as converting the source code in the source files into assembly code, which can be used as input to the assembly module. Optionally, the compilation module can also perform syntax checking on the source code. If the check is error-free, the source code is converted into assembly code; if syntax errors exist, prompts can be output to suggest syntax corrections. Optionally, the compilation module may include one or more compilers. The assembly module is used to assemble the output of the compilation module (i.e., assembly code), which can be understood as converting the assembly code into a machine-executable file, such as a binary file, also known as an object file. For example, the object file may include .o files, .obj files, etc. The linking module is used to link the output of the assembly module (e.g., object files), for example, linking multiple object files with dependencies to form an artifact. For example, source file 1 is processed by the assembler module to obtain object file 1, and source file 2 is processed by the assembler module to obtain object file 2. Assuming that object file 1 depends on object file 2, the linker module links object file 2 to object file 1, thus obtaining the output corresponding to source file 1. This process will be described in detail later. Figure 2 illustrates the compilation system. It is worth noting that Figure 2 uses a single source file as an example. It should be understood that a requirement / idea often requires multiple source files to support it, and the collection of these source files is also called a "source code project (abbreviated as: code project)". In other words, a code project contains multiple source files, each of which can be compiled using the compilation system shown in Figure 2.

[0089] For ease of understanding, the following text uses a code project as an example to illustrate the compilation process of the code project using the compilation system shown in Figure 2. Optionally, the code project can be a code project formed based on application (APP) development, application function development, operating system development, operating system function development, etc.

[0090] Understandably, a code project needs to be written before compilation. The process of writing the code project is called the "programming phase / process." The process of compiling the code project after it is written is called the "compilation phase / process." The "programming phase" and the "compilation phase" will be explained below.

[0091] I. Programming stage.

[0092] The programming phase refers to the stage where programmers write source files based on requirements. As mentioned earlier, a code project often consists of more than one source file, and this number increases as functionality / business expands. To facilitate source file management, modular programming can be used in the programming phase. Modular programming can be understood as breaking down requirements into multiple sub-requirements (or multiple functions), each sub-requirement corresponding to one or more modules, ultimately forming a modular code project. For example, as shown in Figure 3A, the code project includes N modules, where N is a positive integer, and each module includes one or more source files. Continuing with Figure 3A, in the programming phase, programmers can also write script files for each module. The script files include descriptive information for the module, and optionally, the descriptive information may include at least one of the following:

[0093] (1) The name of this module.

[0094] (2) Information about all source files contained in this module. For example, the information about source files includes the path and name of the source file.

[0095] II. Compilation stage.

[0096] Understandably, after the programming phase, the resulting code project can be compiled into a build system. The compilation phase can include the initial compilation, as well as subsequent processes such as modifying source files, adding new source files, and adding new modules, which will be explained in detail below.

[0097] A. Initial compilation process.

[0098] The initial compilation process refers to the first time the code project is compiled by the compilation system. Currently, the initial compilation process uses a full compilation method. A full compilation means that every source file in every module of the code project is compiled by the compilation system. For example, in Figure 3A, each source file is compiled, resulting in the artifacts for each source file. The set of artifacts for all source files constitutes the artifacts of the code project.

[0099] For example, as shown in Figure 3A, module 1 includes source file 1 and source file 2. Source file 1 is converted into assembly code by the compiler module in the compilation system, and then converted into object files, such as .o file 1, by the assembly module. Similarly, source file 2 is converted into assembly code by the compiler module in the compilation system, and then converted into object files, such as .o file 2. Therefore, after passing through the compiler module and the assembly module, module 1 obtains the various object files of module 1, including .o file 1 and .o file 2. .o file 1 and .o file 2 can also be understood as intermediate products of module 1. The same principle applies to modules 2, 3, etc. Therefore, the assembly module can obtain the object files corresponding to each source file in all modules. Afterwards, the assembly module can also establish the dependencies between all object files. One possible approach is that the assembly module determines the dependencies between object files by parsing the function structures of each source file. For example, if source file A references source file B through functions such as import or include, it indicates that source file A and source file B have a dependency relationship, that is, object file A corresponding to source file A has a dependency relationship with object file B corresponding to source file B. Thus, the assembly module obtains the dependencies between all object files. Then, as shown in Figure 3A, the object files enter the linking module. The linking module generates corresponding artifacts based on all object files and their dependencies. For example, assuming object file 1 (i.e., .o file 1) depends on object file 2 (i.e., .o file 2), the linking module links .o file 2 to .o file 1 (e.g., copying the code from .o file 2 to .o file 1), forming artifact 1 for .o file 1. Assuming .o file 2 depends on .o file 3, the linking module links .o file 3 to .o file 2, forming artifact 2 for .o file 2. Therefore, after the linking module, the artifacts corresponding to each source file are obtained, and the set of artifacts corresponding to all source files constitutes the artifact of the code project.

[0100] The above describes the initial compilation process of the code project. It's important to note that the intermediate artifacts (i.e., object files) generated during the initial compilation, along with the dependencies between these object files, need to be stored for later use.

[0101] B. The process of modifying the source file.

[0102] After the initial compilation, the programmer may modify the source files. Modified source files need to be recompiled to obtain the corresponding output. For example, as shown in Figure 3B, source file 1 is modified, and the modified source file 1 needs to be recompiled. In this case, incremental compilation can be used. Incremental compilation utilizes the intermediate output (i.e., object files) generated during the initial compilation process and the dependencies between object files to recompile the modified source files. For example, as shown in Figure 3B, the modified source file 1 enters the compilation system, and after passing through the compilation module and the assembly module, object file 1 is obtained. ， For example, .o file 1 ， Then, the assembly module replaces .o file 1 in the stored intermediate output with .o file 1. ， Understandably, .o file 1 is replaced with .o file 1. ， Afterwards, other object files that originally depended on .o file 1 also need to re-enter the linker module. For example, if .o file 2 originally depended on .o file 1, then after .o file 1 is replaced by .o file 2... ， After that, .o file 1 ， Both the .o file 2 and the modified source file 1 need to enter the linker module. After passing through the linker module, the modified product 1 is obtained. ， and product 2 corresponding to source file 2 ， This process utilizes the intermediate artifacts generated during the initial compilation, hence the term incremental compilation. It should be noted that Figure 3C illustrates this using source file 1 as an example; however, if other source files are modified, incremental compilation is still used, and the principle remains the same.

[0103] C. The process of adding a new source file.

[0104] After the initial compilation, one or more source files may be added to the code project. For example, as shown in Figure 3C, a new source file 'a' is added to module 1. The newly added source file 'a' needs to be compiled to obtain the corresponding output. It's important to note that since source file 'a' is new and hasn't been compiled yet, the intermediate output stored in the assembly module does not include the object file corresponding to source file 'a', nor does it include the dependencies between the object file corresponding to source file 'a' and other object files. In this case, compiling only source file 'a' may result in compilation errors. For example, after source file 'a' is processed by the compilation module and the assembly module to obtain the corresponding object file 'a', the assembly module cannot determine which object files have dependencies on object file 'a', and therefore cannot determine which object files need to re-enter the linker module, potentially leading to compilation errors. To avoid compilation errors, a full compilation approach can be used when a new source file is added. For example, as shown in Figure 3C, after adding source file 'a', every source file in all modules enters the compilation system to obtain the output corresponding to each source file, including the output 'a' corresponding to the newly added source file 'a'. The process of full compilation has been described previously and will not be repeated here.

[0105] D. The process of adding a new module.

[0106] After the initial compilation, one or more modules may be added to the code project. For example, as shown in Figure 3D, module 'a' is added to the code project. Module 'a' can include one or more source files. The newly added module 'a' needs to be compiled to obtain the corresponding artifacts. It should be noted that since module 'a' is new and has not yet been compiled, the intermediate artifacts stored in the assembly module do not contain the object file corresponding to module 'a', nor do they contain the dependencies between the object file corresponding to module 'a' and other object files. In this case, if only module 'a' is compiled, compilation errors may occur. For example, after module 'a' is compiled and assembled to obtain the intermediate artifact (object file) corresponding to module 'a', the assembly system cannot determine the dependencies between the object file of module 'a' and other object files, and therefore cannot determine which object files need to be re-entered into the linker module, which may lead to compilation errors. To avoid this compilation process, a full compilation approach can be used when adding a new module. For example, as shown in Figure 3D, after adding module 'a', every source file in all modules enters the compilation system to obtain the artifact corresponding to each source file. The process of full compilation has been described above and will not be repeated here.

[0107] The above examples illustrate the compilation process of the code project using the compilation system shown in Figure 2. As can be seen from the above, the initial compilation of the code project uses a full compilation. Incremental compilation can be used for modified source files, but for scenarios involving newly added source files or modules, a full compilation is still required. The specific reasons have been described above and will not be repeated. It should be understood that full compilation is time-consuming (especially for large code projects). If a full compilation is performed for the initial compilation and for every newly added module / source file after the initial compilation, it will severely impact the development schedule.

[0108] In view of this, embodiments of this application provide a solution that, for initial compilation scenarios, avoids full compilation as much as possible to reduce compilation time. For example, if a code project includes N modules, and the first module (which has not been compiled before) needs to be compiled, then the other modules that have dependencies on the first module are identified, and the first module and the other modules that have dependencies on the first module are compiled for the first time; modules that do not have dependencies on the first module do not need to be compiled. Therefore, in initial compilation scenarios, full compilation is not required, which helps to shorten the software development schedule.

[0109] Furthermore, if a new source file is added to the first module and the first module needs to be recompiled, then all other modules that depend on the first module must be recompiled, including the first module itself. Modules that do not depend on the first module do not need to be recompiled. Therefore, even when adding new source files to a module, a full compilation is not required, which helps to shorten the software development timeline.

[0110] Furthermore, when adding a new module to a code project, if the new module needs to be compiled, all other modules that have dependencies on the new module must be identified, and both the new module and its dependencies must be recompiled. Modules that do not have dependencies on the new module do not need to be compiled. Therefore, in the case of adding a new module, a full compilation is not required, which helps to shorten the software development schedule.

[0111] The technical solutions provided in the embodiments of this application will be described in detail below.

[0112] For example, Figure 4 is a schematic diagram of a compilation architecture provided in an embodiment of this application. As shown in Figure 4, the compilation architecture includes a dependency determination module and a compilation system. The dependency determination module is used to determine the dependencies between various modules in the code project. Regarding the compilation system in Figure 4, please refer to the preceding description, which will not be repeated here. It should be noted that Figure 4 uses the example of the dependency determination module being located outside the compilation system; optionally, the dependency determination module can also be located inside the compilation system, for example, before the compilation modules within the compilation system.

[0113] Please compare Figure 4 and Figure 2. In Figure 2, the dependency determination module is not included before the compilation system, so all modules in the code project are compiled, i.e., a full compilation. In Figure 4, a dependency determination module is added before the compilation system to identify multiple modules with dependencies. These modules can be compiled, while other modules do not need to be compiled. Therefore, the dependency determination module in Figure 4 can select / filter modules in the code project. The selected / filtered modules are compiled, while other modules do not need to be compiled, thus avoiding a full compilation as much as possible.

[0114] The following text continues with a code project as an example to illustrate the compilation process of the code project using the compilation architecture shown in Figure 4.

[0115] As mentioned earlier, the code project needs to be written before it can be compiled. The process of writing the code project is called the "programming phase / process". The compilation process after the code project is written is called the "compilation phase / process". The "programming phase" and "compilation phase" will be explained below.

[0116] I. Programming stage.

[0117] To facilitate source file management, a modular programming approach can be adopted during the programming phase. Modular programming has already been described previously and will not be repeated here. For example, as shown in Figure 5A, the code project includes N modules, each containing one or more source files. In this embodiment, during the programming phase, the programmer can also write a script file (also called a configuration file or other name) for each module, which includes descriptive information for that module. Optionally, the descriptive information includes at least one of the following:

[0118] (1) The name of this module.

[0119] Optionally, the module name can be a string, an array of strings, or other forms. The module name can be defined by the programmer or automatically generated by the device; there are no restrictions.

[0120] (2) Information on all source files contained in this module.

[0121] Optionally, the source file information includes the source file's path, name, etc. The source file path is the storage path / address of the source file, and the source file name is the name of the source file. Taking module 1 as an example, module 1 includes source file 1 and source file 2, so the script file of module 1 includes information about source file 1 and source file 2.

[0122] (3) Declaration of dependencies for this module.

[0123] In this embodiment, the dependency declaration of this module (hereinafter referred to as "dependency declaration") is used to declare other modules that have a dependency relationship with this module. For example, the dependency declaration is used to declare: other modules that this module depends on, that is, which modules this module depends on. Which modules this module depends on can be understood as: which modules this module needs to rely on to achieve its function, or it can also be called: which modules this module references / calls. Assuming that module 1 depends on module 2, it can be expressed as: module 1 <— module 2, where the arrow "<—" represents the dependency relationship, and the arrow points from module 2 to module 1, representing that module 1 depends on module 2. It can be understood that a module may depend on one or more other modules. For example, as shown in Figure 5B, taking this module as module 1 as an example, the dependency relationship between module 1 and other modules is illustrated. As shown in Figure 5B, module 1 depends on module 2 and module 3, so the arrows of module 2 and module 3 in Figure 5B both point to module 1. Taking module 1 depending on module 2 in Figure 5B as an example, optionally, module 1 and module 2 can satisfy at least one of the following conditions:

[0124] a. Module 1 calls Module 2 through an interface. The interface can be any type of function interface and is not limited thereto. It is understood that Module 1 includes one or more source files, and Module 2 also includes one or more source files. Module 1 calling Module 2 through the interface can include: any source file in Module 1 calling any source file in Module 2 through the interface.

[0125] b. Function 1 corresponding to module 1 includes function 2 corresponding to module 2, or in other words, function 2 corresponding to module 2 is a sub-function of function 1 corresponding to module 1. For example, function 1 corresponding to module 1 is an audio call function, and function 2 corresponding to module 2 is a microphone call function. That is, function 2 is a sub-function of function 1. In other words, the implementation of function 1 depends on function 2, so module 1 depends on module 2.

[0126] c. Function 1 corresponding to Module 1 is an extension / additional function of Function 2 corresponding to Module 2. For example, Function 2 corresponding to Module 2 is a call function, and Function 1 corresponding to Module 1 is a call recording function. When using Function 2 (call function), the user may use Function 1 (call recording function). That is, Function 1 is based on Function 2 and is an additional / extension of Function 2. Therefore, Module 1 depends on Module 2.

[0127] The above describes several possible scenarios where module 1 depends on module 2. It should be noted that, besides the scenarios mentioned above, module 1 may depend on module 2 in other ways, which will not be listed here. As mentioned above, each module's script file includes a dependency declaration, which declares which modules this module depends on. For example, the dependency declaration may include information about other modules that this module depends on, such as module names. Continuing with Figure 5B as an example, if module 1 depends on modules 2 and 3, then module 1's script file includes a dependency declaration that includes the names of modules 2 and 3, and specifies that module 1 depends on modules 2 and 3.

[0128] Optionally, the dependency declaration of this module can also declare: other modules that depend on this module, that is, which modules depend on this module. Which modules depend on this module can be understood as: which modules' functionality depends on this module, or which modules reference / call this module. Assuming module 1 is dependent on module 4, it can be represented as: module 4 <— module 1, where the arrow "<—" represents the dependency relationship. The arrow points from module 1 to module 4, indicating that module 1 is dependent on module 4 or module 4 depends on module 1. It is understood that a module may be dependent on one or more other modules. For example, as shown in Figure 5B, continuing with the example of this module being module 1, the dependency relationship between module 1 and other modules is illustrated. As shown in Figure 5B, module 1 is dependent on both module 4 and module 5, so in Figure 5B, module 1 points to module 4 and module 5 respectively via two arrows. Taking the example of module 1 being dependent on module 4 in Figure 5B, optionally, module 1 and module 4 can satisfy at least one of the following conditions:

[0129] a) Module 4 calls Module 1 through an interface. The interface can be any type of function interface, without limitation. It is understood that Module 4 includes one or more source files, and Module 1 also includes one or more source files. Module 4 calling Module 1 through the interface can include: any source file in Module 4 calling any source file in Module 1 through the interface.

[0130] b. Function 4 corresponding to module 4 includes function 1 corresponding to module 1, or in other words, function 1 corresponding to module 1 is a sub-function of function 4 corresponding to module 4. For example, function 4 corresponding to module 4 is instant messaging, and function 1 corresponding to module 1 is audio call. That is, function 1 is a sub-function of function 4. In other words, function 4 depends on function 1, so module 4 depends on module 1, that is, module 1 is depended on by module 4.

[0131] c. Function 4 corresponding to module 4 is an extension / additional function of function 1 corresponding to module 1. For example, function 4 corresponding to module 4 is a call recording and sharing function, and function 1 corresponding to module 1 is a call recording function. When using function 1 (call recording function), the user may use function 4 (call recording and sharing function). That is, function 4 is based on function 1 and is an additional / extension function of function 1. Therefore, module 4 depends on module 1, that is, module 1 is depended on by module 4.

[0132] The above describes several possible scenarios where module 1 is dependent on module 4. It should be noted that, besides the scenarios mentioned above, there may be other situations where module 1 is dependent on module 4, which will not be listed here. As mentioned above, each module's script file includes a dependency declaration for that module, which declares which modules depend on it. For example, the dependency declaration may include information about other modules that depend on it, such as their names. Continuing with Figure 5B as an example, if module 1 is dependent on both module 4 and module 5, then module 1's script file includes a dependency declaration that includes the names of module 4 and module 5, and specifies that module 1 is dependent on both modules 4 and 5.

[0133] (4) Type declaration for this module.

[0134] In this embodiment, the type declaration of this module is used to declare the type of this module. Optionally, the type of this module can be the output type corresponding to this module, that is, what type of output this module is to be compiled into. For example, the type may include a library file or an executable file. Taking a library file as an example, it may include: static library files (e.g., .lib files), dynamic library files (e.g., .dll files), database files (e.g., .db files, .mdb files, etc.) or other library files. Taking an executable file as an example, such as .exe files, .com files, .bat files, etc., are not limited. For example, if the script file of module 1 includes a type declaration, and this type declaration is used to declare that the type of module 1 is a dynamic library file, then the output formed after compiling module 1 is a dynamic library file. As another example, if the script file of module 2 includes a type declaration, and this type declaration is used to declare that the type of module 2 is an executable file, then the output formed after compiling module 2 is an executable file.

[0135] The above describes the script files within the module shown in Figure 5A. It should be noted that, compared to the script files in Figure 3A, the script files in Figure 5A include dependency declarations and type declarations for this module.

[0136] The above examples illustrate the programming phase of a code project. Continuing with Figure 5A as an example, after programming is complete, the code project can enter the dependency determination module to determine the dependencies between modules within the code project. As mentioned earlier, each module's script file includes dependency declarations, used to declare other modules that have dependencies on this module. Therefore, the dependency determination module can determine the dependencies of each module based on the dependency declarations in each module's script file, and then summarize the dependencies of each module to obtain the total dependencies between all modules within the code project.

[0137] Taking a code project comprising modules 1 to 8 as an example, as shown in Figure 5C, the dependency relationships between the modules in this code project are illustrated. The process for determining the dependency relationships in this code project, as exemplarily, includes:

[0138] The dependency determination module, based on the dependency declarations in Module 1's script file, determines that Module 1 depends on Module 2 and Module 3, thus forming two chains: "Module 1 <- Module 2" and "Module 1 <- Module 3". Optionally, before determining the modules that Module 1 depends on, it can first determine whether Module 1 is of type 1 or type 2 based on the type declarations in its script file. If it is type 1, there is no need to search for the modules that Module 1 depends on; if it is type 2, the modules that Module 1 depends on, i.e., Module 2 and Module 3, can be determined based on the dependency declarations in Module 1's script file. For example, type 1 can be a dynamic library or an executable file. Type 2 can be other types besides type 1, such as a static library.

[0139] Taking the dependency chain "Module 1 <— Module 2" as an example, the dependency determination module, based on the dependency declaration in Module 2's script file, determines that Module 2 depends on Module 7. Therefore, "Module 1 <— Module 2" extends to "Module 1 <— Module 2 <— Module 7". Optionally, before determining the module that Module 2 depends on, it can also be determined whether Module 2 is of type 1 or type 2 based on the type declaration in Module 2's script file. If it is type 1, there is no need to find the module that Module 2 depends on; if it is type 2, the module that Module 2 depends on, i.e., Module 7, is determined based on the dependency declaration in Module 2's script file.

[0140] Next, the dependency determination module, based on the dependency declarations in module 7's script file, determines that module 7 depends on module 8, which then extends to "module 1 <- module 2 <- module 7 <- module 8". Optionally, before determining the modules that module 7 depends on, it can also determine whether module 7 is of type 1 or type 2 based on the type declarations in module 7's script file. If it is type 1, there is no need to find the modules that module 7 depends on; if it is type 2, then the modules that module 7 depends on, i.e., module 8, are determined based on the dependency declarations in module 7's script file.

[0141] The dependency determination module determines that module 4 depends on module 1 based on the dependency declarations in module 4's script file. Therefore, "module 1 <- module 2 <- module 7 <- module 8" is extended to "module 4 <- module 1 <- module 2 <- module 7 <- module 8". Optionally, the type of module 4 can also be determined based on the type declarations in module 4's script file before this step; this will not be repeated here. The dependency determination module determines that module 5 depends on module 1 based on the dependency declarations in module 5's script file. Therefore, "module 1 <- module 2 <- module 7 <- module 8" is extended to "module 5 <- module 1 <- module 2 <- module 7 <- module 8". Optionally, the type of module 5 can also be determined based on the dependency declarations in module 5's script file before this step; this will not be repeated here.

[0142] Taking the dependency chain "Module 1 <— Module 3" as an example, the dependency relationship is determined by the dependency declaration in Module 3's script file, which shows that Module 3 depends on Module 6. Therefore, "Module 1 <— Module 3" extends to "Module 1 <— Module 3 <— Module 6". Optionally, before this, the type of Module 3 can be determined based on the type declaration in Module 3's script file.

[0143] Therefore, through the above process, the overall dependency relationships between the modules of the code project, including modules 1 to 8, are obtained. This overall dependency relationship can be stored for later use. In practical applications, the overall dependency relationship can be stored in various forms such as array pointers or lists, without limitation. It should be noted that Figure 5C is only a simple example of a dependency relationship; in practical applications, the dependency relationships between modules in the code project can be more complex than those shown in Figure 5C.

[0144] As mentioned earlier, the dependency determination module determines the dependencies of each module based on the dependency declarations in each module's script file, and then summarizes the dependencies of each module to obtain the total dependencies between all modules. The following section, in conjunction with Figure 5D, details this process. Figure 5D is a flowchart illustrating the determination of the total dependencies between modules according to an embodiment of this application. This process can be applied to the dependency determination module. For example, the dependency determination module includes four units: a module parsing unit, a dependency parsing unit, a dependency generation unit, and a module target object unit. These four units enable the establishment of the total dependencies between modules. Figure 5D can also be understood as an information interaction diagram between these four units. For example, as shown in Figure 5D, the process includes:

[0145] S401, the module parsing unit obtains the basic information of module 1 through the script file of module 1. Optionally, the basic information of module 1 may include the name and path of module 1.

[0146] S402, the module resolution unit sends a request to the module target object unit to request the creation of the target object of module 1. Optionally, the target object can be a class or a function. Taking a class as an example, after creating the class of module 1, the instance corresponding to that class can store the basic information of module 1.

[0147] S403 indicates that the module target object unit has successfully created the module and sends a notification to the module parsing unit. Optionally, S403 may or may not be executed; therefore, S403 is represented by a dashed line in the diagram.

[0148] S404, the module resolution unit sends a request to the dependency resolution unit to request the resolution of the dependencies of module 1.

[0149] S405, the dependency resolution unit uses the script file of module 1 to determine information about other modules that have dependencies on module 1. For example, the dependency resolution unit uses the dependency declarations in the script file of module 1 to determine information about other modules that have dependencies on module 1.

[0150] S406, the dependency resolution unit sends a request to the module target object unit to request the setting of the dependency information of the target object of module 1. As mentioned above, the module target object unit creates a class corresponding to module 1, and the instance corresponding to this class stores the basic information of module 1. S406 can set the dependency relationship of the class, that is, the information of other classes (corresponding to other modules) that have a dependency relationship with the class.

[0151] Optionally, before S405, the dependency resolution unit can determine the type of module 1 through the type declaration in module 1's script file. If it is type 1, it means that module 1 is an independent module. In this case, S405 can be skipped, and S406 can be executed directly. In S406, the request sent by the dependency resolution unit to the module target object unit indicates that the dependency information of the target object of module 1 is empty. If module 1 is type 2, then S405 is executed, and the request sent by the dependency resolution unit to the module target object unit in S406 includes information about the dependent modules of module 1 (e.g., module names).

[0152] S407 indicates that the module target object unit has successfully set the parameters and sends a feedback signal to the module parsing unit. Optionally, S407 may or may not be executed; therefore, it is represented by a dashed line in the diagram.

[0153] S408, the dependency resolution unit sends a request to the dependency generation unit to request the dependency relationship of module 1.

[0154] S409, the dependency generation unit obtains the basic information of the target object of module 1 from the module target object unit.

[0155] S410, the dependency generation unit obtains the dependency information of the target object of module 1 from the module target object unit.

[0156] S411, the dependency generation unit generates the dependency relationship of module 1 based on the basic information and dependency information of the target object of module 1.

[0157] For example, please refer to Table 1 below for an example of the dependencies of module 1.

[0158] Table 1: Dependencies of Module 1

[0159] S412, the dependency generation unit sends a success indication to the module resolution unit to indicate that the dependency of module 1 has been successfully generated.

[0160] Steps S401 to S412 above describe the process of determining the dependencies of module 1. The same principle applies to other modules besides module 1. Therefore, for each module, we can obtain a result in a form similar to Table 1 above.

[0161] S413, the model parsing unit sends a request to the dependency generation unit to obtain the total dependencies of all modules.

[0162] S414, the dependency generation unit summarizes the dependencies of all modules to obtain the total dependencies of all modules.

[0163] Taking a code project comprising modules 1 to 6 as an example, each module in modules 1 to 6 has a dependency relationship similar to Table 1 above. The dependency generation unit obtains the total dependency relationship between all modules by traversing the table. For example, continuing with Figure 5C, the dependency generation unit determines that module 1 depends on modules 2 and 3 based on the dependency relationship of module 1 (e.g., Table 1 above), thus forming "module 1 <— module 2". It also determines that module 2 depends on module 7 based on the dependency relationship of module 2 (similar to Table 1 above), thus extending "module 1 <— module 2" to "module 1 <— module 2 <— module 7", and so on, to obtain the total dependency relationship between all modules.

[0164] It should be noted that the overall dependency relationship between the modules mentioned above is different from the dependency relationship between the target files mentioned in Figures 3A to 3D above. The differences may include: (1) Different generation timing: the overall dependency relationship between modules can be generated before the first compilation, but the dependency relationship between target files is generated after the first compilation (belonging to the dependency relationship between intermediate products in the first compilation process). (2) Different dimensions: the overall dependency relationship between modules is used to describe the dependency relationship between modules, but the dependency relationship between target files describes the dependency relationship between files. The two have different dimensions / granularities.

[0165] The above examples illustrate the process of determining the overall dependencies (hereinafter referred to as the first dependencies) among all modules in a code project. After determining the overall dependencies among modules (for example, the dependencies shown in Figure 5C), the code project can be compiled, i.e., the compilation phase begins.

[0166] II. Compilation stage.

[0167] The compilation process can include: initial compilation, as well as processes such as modifying source files, adding new source files, and adding new modules. These will be explained in detail below.

[0168] A. Initial compilation process.

[0169] The initial compilation process refers to the first compilation of the code project before any source files have been compiled. Assume the code project contains N modules, meaning none of the N modules have been compiled. It should be understood that each module contains one or more source files; therefore, all source files for all N modules have not been compiled.

[0170] In this embodiment, the initial compilation process of the code project can be either a full compilation or a partial compilation. Taking a full compilation as an example, each source file in each module of the code project needs to be compiled into the compilation system for the first time. The full compilation process has been described previously and will not be repeated. Taking a partial compilation as an example, only some modules in the code project need to be compiled into the compilation system for the first time; it is not necessary for all modules to be compiled for the first time. For example, as shown in Figure 6A, the code project includes N modules. Some of the N modules are compiled into the compilation system for the first time, while the other modules do not need to be compiled for the first time. Optionally, the partial modules can be modules that have dependencies among the N modules. For example, in Figure 6A, module 1 and module 2 have a dependency relationship; therefore, only module 1 and module 2 need to be compiled for the first time, and the other modules do not need to be compiled.

[0171] The following description, with reference to Figure 6B, illustrates the partial compilation process in the initial compilation scenario of this application. Figure 6B is a flowchart illustrating a compilation method provided in an embodiment of this application. This method can be applied to the compilation architecture shown in Figure 6A, where all source files of the code project are uncompiled, i.e., it is suitable for the initial compilation scenario of the code project. As shown in Figure 6B, the process includes:

[0172] S600, determine the first module to be compiled.

[0173] Alternatively, one possible approach with the S600 is for the programmer to specify the first module. The process of programmer-specified modules will be explained in Figure 12 later.

[0174] S601 determines whether the first module is of type 1 or type 2; if it is type 1, only compile the first module for the first time; if it is type 2, then execute S602.

[0175] For example, the first type can be a dynamic library or an executable file. The second type can be other types besides the first type, such as a static library. This is because if a module's type is a dynamic library or an executable file, it means that the module is independent and has no dependencies on other modules. Therefore, if the first module's type is a dynamic library or an executable file, it means that the code project does not contain other modules that depend on the first module, i.e., only the first module needs to be compiled. If the first module's type is a static library, it means that the code project contains other modules that depend on the first module, and it is necessary to determine which modules depend on the first module, i.e., to execute S602. It is understandable that before S601, there may also be a step: determining the type of the first module. One possible way is to determine the type of the first module based on the type declaration in the first module's script file. The type declaration in the script file has been described above and will not be repeated. In addition, it should be noted that S601 is an optional step, which can be executed or not, so S601 is represented by a dashed line in Figure 6B.

[0176] S602, based on the first module and the overall dependency relationship, determine the other modules in the code project that have dependencies on the first module. The first dependency relationship is used to describe the dependencies between various modules in the code project.

[0177] It is understandable that, prior to S602, the process may also include: generating the first dependency. The process of generating the first dependency has been explained in detail in Figure 5D above and will not be repeated here. Optionally, other modules that have a dependency on the first module may include: other modules that the first module depends on; optionally, it may also include: other modules that depend on the first module.

[0178] Taking the first dependency relationship as shown in Figure 5C as an example, assuming the first module is module 1 in Figure 5C, based on module 1 and the first dependency relationship, the other modules that module 1 depends on are determined, including: module 2, module 3, and modules 6 to 8. Module 1 directly depends on modules 2 and 3, and indirectly depends on modules 6 to 8. Optionally, continuing as shown in Figure 5C, based on module 1 and the first dependency relationship, other modules that depend on module 1 can also be determined, including: module 4 and module 5. Modules 4 and 5 both directly depend on module 1. Therefore, by using the first dependency relationships among all modules, all modules that have dependencies on the first module can be quickly found, resulting in high efficiency.

[0179] S603 compiles the first module and other modules that depend on the first module.

[0180] For example, the first module and other modules that depend on the first module are compiled by the compilation system. It should be noted that the first module may not have been compiled, but other modules that depend on the first module may or may not have been compiled; this is not a limitation.

[0181] In the above embodiments, after generating the total dependencies between all modules (i.e., the first dependencies), this total dependencies are stored. To compile the first module, all modules that depend on the first module can be quickly found based on the total dependencies. In other embodiments, it is not necessary to generate the total dependencies between all modules to determine all modules that depend on the first module. For example, after determining the first module to be compiled, the second module that depends on the first module is determined based on the first module and its dependency declarations. Then, based on the second module and its dependency declarations, the third module that depends on the second module is determined, and so on. By searching each module one by one, all modules that the first module depends on are determined, and then the first module and all modules that depend on the first module are compiled. The process of searching each module one by one is described below.

[0182] For example, after determining the first module to be compiled (e.g., the module specified by the programmer), the first module is used as the current module, and S701 and S702 as shown in Figure 7A are executed on the current module.

[0183] S701 determines whether the current module is of type 1 or type 2. If it is type 1, the process ends; if it is type 2, S702 is executed. Optionally, S701 may or may not be executed, so it is represented by a dashed line in the diagram.

[0184] S702, based on the current module and its dependency declarations, determine the modules that the current module depends on.

[0185] For example, as shown in Figure 7B, when the first module is the current module, it is determined that the first module depends on the second module, so the dependency relationship between the first module and the second module is represented by an arrow.

[0186] After determining the second module, it becomes the current module. Steps S701 and S702 in Figure 7A are re-executed on the current module (i.e., the second module). This involves determining the type of the current module (i.e., the second module). If it's type one, the process ends; if it's type two, the modules that the current module (i.e., the second module) depends on are determined based on the current module (i.e., the second module) and its dependency declarations. For example, continuing as shown in Figure 7B, when the second module is the current module, it's determined that the second module depends on the third module. Therefore, the dependency relationship between the second and third modules is represented by arrows.

[0187] Similarly, after determining the third module, the third module becomes the current module. S701 and S702 in Figure 7A are re-executed for the current module (i.e., the third module), and so on, until the endpoint is found. For example, as shown in Figure 7B, the endpoint is module P. Module P will also become the current module and S701 to S702 will be re-executed. However, when S701 is re-executed, the result is that the current module (i.e., module P) is of type 1, thus ending the process. Therefore, module P is the endpoint.

[0188] Therefore, as shown in Figure 7B, after determining the first module to be compiled, multiple modules that the first module depends on are identified by searching each module individually. These multiple modules form the link shown in Figure 7B (i.e., the link enclosed by the dashed line). This link includes multiple nodes, each corresponding to a module. The starting node of this link (i.e., the second module) is dependent on the first module, and the ending node is the Pth module. Furthermore, in every pair of adjacent nodes on this link, the next node is dependent on the previous node. In other words, except for the starting node (i.e., the second module), which is directly dependent on the first module, all other nodes are indirectly dependent on the first module. That is, all modules on this link are dependent on the first module. Therefore, if the first module is to be compiled, all modules on this link must be compiled.

[0189] It should be noted that Figure 7B uses one link as an example, but optionally, it may include multiple links. For example, after determining the first module (e.g., the module specified by the programmer), the first module becomes the current module. S701 and S702 in Figure 7A are executed on the current module, determining that the modules the first module depends on include the second and fourth modules, as shown in Figure 7C. The dependencies between the second and fourth modules and the first module are represented by arrows. Then, the second module becomes the current module, and S701 to S702 are re-executed on the current module, and so on, until the endpoint is found, as shown in module P in Figure 7C. Then, the fourth module becomes the current module, and S701 to S702 are re-executed on the current module, and so on, until the endpoint is found, as shown in module Q in Figure 7C. Therefore, in Figure 7C, the first module directly depends on the second and fourth modules, and the second and fourth modules each lead to two links (links enclosed by dashed lines), and all modules on these two links are depended upon by the first module. Therefore, if the first module is to be compiled, all modules on both of these links must be compiled.

[0190] It should be noted that in the embodiments shown in Figures 7A to 7C, it is determined which modules the first module depends on. Optionally, in other embodiments, it may also be determined which modules the first module depends on.

[0191] For example, after determining the first module to be compiled (e.g., the module specified by the programmer), the first module is used as the current module, and S801 and S802 as shown in Figure 8A are executed on the current module.

[0192] S801 determines whether the current module is of type 1 or type 2. If it is type 1, the process ends; if it is type 2, S802 is executed. Optionally, S801 may or may not be executed, so it is represented by a dashed line in the diagram.

[0193] S802, based on the current module and its dependency declarations, determine the modules that the current module depends on.

[0194] For example, as shown in Figure 8B, when the first module is the current module, it is determined that the first module is dependent on the sixth module. Therefore, the dependency relationship between the sixth module and the first module is represented by an arrow.

[0195] After determining the sixth module, the sixth module becomes the current module, and steps S801 and S802 in Figure 8A are re-executed for the current module (i.e., the sixth module). Specifically, the type of the current module (i.e., the sixth module) is determined. If it is of type one, the process ends; if it is of type two, the modules that the current module (i.e., the sixth module) depends on are determined based on the current module (i.e., the sixth module) and its dependency declarations. For example, continuing as shown in Figure 8B, when the sixth module is the current module, it is determined that the sixth module depends on the seventh module, so the dependency relationship between the sixth and seventh modules is represented by arrows.

[0196] Similarly, after determining the seventh module, the seventh module becomes the current module. S801 and S802 in Figure 8A are re-executed for the current module (i.e., the seventh module), and so on, until the endpoint is found. For example, as shown in Figure 8B, the endpoint is the Mth module. The Mth module also becomes the current module and S801 and S802 are re-executed. However, when S801 is re-executed, the result is that the current module (i.e., the Mth module) is of type 1, thus ending the process. Therefore, the Mth module is the endpoint.

[0197] Therefore, as shown in Figure 8B, after determining the first module to be compiled, multiple modules that the first module depends on are gradually identified. These multiple modules form the link shown in Figure 8B (i.e., the link enclosed by the dashed line). This link includes multiple nodes, each corresponding to a module. The starting node of this link (i.e., the sixth module) depends on the first module, and the ending node is the Mth module. Furthermore, in every pair of adjacent nodes on this link, the next node depends on the previous node. In other words, except for the starting node (i.e., the sixth module) which directly depends on the first module, all other nodes indirectly depend on the first module; that is, all modules on this link depend on the first module. Therefore, if the first module is compiled, all modules on this link are also compiled.

[0198] It should be noted that Figure 8B uses one link as an example, but optionally, it may include multiple links. For example, after determining the first module (e.g., the module specified by the programmer), the first module becomes the current module, and S801 and S802 as shown in Figure 8A are executed on the current module. The modules that the first module depends on are the sixth module and the eighth module, as shown in Figure 8C, with the dependencies between the sixth and eighth modules and the first module represented by arrows. Then, the sixth module becomes the current module, and S801 and S802 are re-executed on the current module (i.e., the sixth module), and so on, until the endpoint is found, such as the Mth module in Figure 8C. Then, the eighth module also becomes the current module, and S801 and S802 are re-executed on the current module (i.e., the eighth module), and so on, until the endpoint is found, such as the Lth module in Figure 8C. Therefore, in Figure 7C, the first module is directly dependent on the sixth and eighth modules, and the sixth and eighth modules each lead to two links (links enclosed by dashed lines), and all modules on these two links depend on the first module. Therefore, if the first module is to be compiled, all modules on both of these links must be compiled.

[0199] The above embodiments illustrate the partial compilation process during the initial compilation of the technical solutions provided in this application. For example, the first module and other modules that depend on the first module are compiled for the first time. Subsequently, the source files in the first module or other modules that depend on the first module may be modified, and the process of modifying the source files is described below.

[0200] B. The process of modifying the source file.

[0201] For example, as shown in Figure 9A, source file 1 in module 1 is modified. If module 1 needs to be recompiled, the dependency determination module can identify other modules that depend on module 1 based on module 1 and the first dependency. Then, module 1 and other modules that depend on module 1 are recompiled, while modules that do not depend on module 1 do not need to be recompiled. Therefore, in this way, a full compilation is unnecessary when source files are modified, reducing compilation time.

[0202] C. The process of adding a new source file.

[0203] For example, as shown in Figure 9B, a new source file 'a' is added to module 1. If module 1 needs to be recompiled, the dependency determination module can identify other modules that depend on module 1 based on module 1 and the first dependency. Then, module 1 and other modules that depend on module 1 are recompiled, while modules that do not depend on module 1 do not need to be recompiled. Therefore, in this way, when a new source file is added to a module, a full compilation is not required, reducing compilation time.

[0204] It should be noted that currently, if the source code files in a code project are modified, incremental compilation is required. Incremental compilation utilizes the intermediate artifacts (i.e., object files) generated during the initial compilation process and the dependencies between these object files. Therefore, the intermediate artifacts (i.e., object files) generated during the initial compilation process and the dependencies between these object files need to be stored. See Figure 3B for a description of this. If the code project is large, there will be many intermediate artifacts, which consumes a significant amount of storage space. In this embodiment, after the source code files in the first module are modified, incremental compilation is not used. Instead, the first module and modules that have dependencies on the first module are re-entered into the compilation system for compilation. Therefore, there is no need to store the intermediate artifacts generated during the initial compilation process, saving storage space; moreover, recompiling all modules with dependencies avoids compilation errors and ensures higher accuracy.

[0205] IV. The process of adding a new module.

[0206] For example, as shown in Figure 10, the code project originally included N modules. After adding module a, the number of modules in the code project becomes N+1. In this embodiment, the increase in the number of modules triggers the dependency determination module to update the dependencies between the modules in the code project. Assuming that before adding module a in Figure 10, the code project included N modules, and the first dependency was dependency 1, which describes the dependencies between the N modules. After adding module a, the code project includes N+1 modules, and dependency 1 is updated to dependency 2, which is the dependency between the N+1 modules. The generation process of dependency 2 is the same as the generation process of the first dependency described above, and will not be repeated.

[0207] After adding a new module, if it needs to be compiled, the other modules that depend on the new module are identified based on the updated dependencies, and both the new module and its dependent modules are compiled. Modules that do not depend on the new module do not need to be compiled. Therefore, in the case of adding a new module, a full compilation is not required, which helps to shorten the software development schedule.

[0208] In some embodiments, the technical solutions of this application can be applied to communication systems. For example, as shown in Figure 11, the communication system includes a terminal device and a server. The server includes a code library and a compilation architecture. The compilation architecture includes a dependency determination module and a compilation system. The code library includes code projects; for details on code projects and the compilation architecture, please refer to the description in Figure 4 above, which will not be repeated here. As shown in Figure 11, the server also includes an access control module; the use of the access control module will be described later. Continuing with Figure 11 as an example, one possible scenario is that the code project is the code project of a large software development project, which may be completed by multiple different programmers, each programmer responsible for different modules or different source files. Each programmer programs on their own terminal device and then uploads their written modules / source files to the code library in the server.

[0209] Based on the communication system shown in Figure 11, please refer to Figure 12, which is a flowchart illustrating a compilation method provided in an embodiment of this application. This method is applicable to the communication system shown in Figure 11, where the code project on the server has not yet been compiled. For example, the code project includes N modules, and none of the N modules have been compiled. It should be understood that each module may include one or more source files, and the fact that none of the N modules have been compiled means that all source files of the N modules have not been compiled. In other words, the flowchart in Figure 12 is applicable to the scenario of the code project being compiled for the first time. As shown in Figure 12, the flowchart includes:

[0210] S1201, the terminal device sends a first compilation instruction to the server, which is used to instruct the first module in the code project to be compiled.

[0211] In one possible implementation, the programmer's terminal device can log in to the server, and the terminal device can provide a designated entry point for the programmer to specify the modules to be compiled in the code project. For example, the designated entry point could be a module identifier corresponding to each module in the code project. Suppose the programmer wants to compile the first module, they click on the module identifier of the first module. Then, the terminal device sends a first compilation instruction to the server, instructing the server to compile the first module in the code project.

[0212] S1202, the server determines the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship.

[0213] One possible scenario is that after receiving the first compilation instruction, the access control module sends a query instruction to the dependency determination module. The dependency determination module, based on the first module and its dependencies, queries for a second module that has a dependency on the first module. Subsequently, the access control module can also return a prompt message to the terminal device, indicating the existence of a second module that depends on the first module, and asking whether to compile the second module. The terminal device can display this prompt message and, in response to user confirmation, send a confirmation compilation instruction to the access control module. Upon receiving the confirmation compilation instruction, the access control module sends a notification message to the dependency determination module, instructing it to compile both the first and second modules.

[0214] Understandably, prior to S1202, the server needs to generate the first dependency relationship. For example, a terminal device can send the server the script file for each of the N modules in a code project, with each script file including a dependency declaration for each module; the server generates the first dependency relationship based on the dependency declaration for each module. The process of generating the first dependency relationship has been described above and will not be repeated here.

[0215] Optionally, before S1202, the following may also be included: the server determines whether the first module has dependencies on other modules based on its type. If so, S1202 is executed; otherwise, S1202 is not required, and only the first module needs to be compiled for the first time. For example, if the first module is of type 1 (e.g., a dynamic library file or an executable file), it is determined that the first module has no dependencies on other modules; if the first module is of type 2 (e.g., a static library file), it is determined that the first module has dependencies on other modules.

[0216] S1203, the server compiles the first module and the second module.

[0217] In some embodiments, the terminal device can also modify the first module (e.g., modify the source code files in the first module), including online or offline modification. For example, with online modification, the terminal device can view and modify the source code files in the first module online. With offline modification, the terminal device can download the source code files of the first module from the server, modify the source code files locally on the terminal device, and then upload the modified first module to the server to replace the original first module with the modified first module. Afterwards, if the modified first module needs to be recompiled, an operation is entered on the terminal device (e.g., clicking the module identifier of the first module). In response to this operation, the terminal device sends a second compilation instruction to the server, which instructs the source code files in the first module to be recompiled. The server determines the third module that has a dependency on the first module based on the first module and the first dependency relationship; and recompiles both the first module and the third module.

[0218] In some embodiments, the terminal device may also add source code files to the first module. For example, if the terminal device uploads a new source code file to the server and specifies that the new source code file is located in the first module, the server adds the new source code file to the first module. Then, to compile the first module, the terminal device sends a third compilation instruction to the server, which instructs the source code files in the first module to be recompiled. Based on the first module and the first dependency, the server determines a fourth module that has a dependency on the first module. The server then recompiles both the first module and the fourth module.

[0219] In some embodiments, programmers can also add modules to the code project, for example, a terminal device uploads a new module to the server. After adding a module, the server can update the first dependency relationship, which includes the dependencies between the new module and the original N modules. In one possible implementation, after adding a module, the terminal device can upload the script file of the new module. The dependency declarations in the script file are used to declare the dependencies between the new module and existing modules. The server updates the first dependency relationship based on the dependency declarations in the script file of the new module.

[0220] In some embodiments, the second module has a dependency relationship with the first module, including: the first module depends on the second module. Optionally, the server can also determine which modules the second module depends on. For example, based on the dependency relationship between the second module and the first module, it is determined that the second module depends on the sixth module, indicating that the first module directly depends on the second module, and the second module directly depends on the sixth module, that is, the first module indirectly depends on the sixth module. In this case, the server can perform the first, second, and sixth modules for initial compilation.

[0221] In other embodiments, the technical solutions of this application can be applied to terminal devices. For example, a terminal device can be a mobile phone, tablet computer, laptop computer, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), or various other devices; in short, this application does not limit the specific type of terminal device. For example, as shown in Figure 13, a code library and compilation architecture are deployed in the terminal device. The compilation architecture includes a dependency determination module and a compilation system. The code library can be created by a programmer to store code projects. For example, a programmer writes the various modules included in the code project on the terminal device and then stores these modules in the code library. The compilation architecture can be pre-configured within the terminal device (e.g., it is factory-installed by default) or downloaded and installed by the user (e.g., the programmer), without limitation. After the code project is written, it can be compiled for the first time. For example, if a programmer wants to compile the first module, they specify the first module on the terminal device (e.g., the terminal device provides a specified entry point through which the module to be compiled in the code library can be specified). After the terminal device determines the first module to be compiled, it can execute S1202 to S1203 in Figure 12.

[0222] Please refer to Figure 14, which is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may be a terminal device or a server as described above. As shown in Figure 14, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0223] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller may serve as the nerve center and command center of the electronic device. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has just used or is recurring. If processor 110 needs to reuse an instruction or data, it can directly retrieve it from the memory. This avoids repeated access, reduces the waiting time of processor 110, and thus improves system efficiency.

[0224] In some embodiments, processor 110 may execute the compilation method provided in the embodiments of this application. When the electronic device is a terminal device as described above, processor 110 may execute the methods of the terminal device as described above, such as the method steps of the terminal device in FIG12. When the electronic device is a server as described above, processor 110 may execute the methods of the server as described above, such as the method steps of the server in FIG12.

[0225] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0226] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0227] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0228] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0229] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0230] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0231] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0232] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0233] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0234] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in conjunction with a tuning switch.

[0235] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in electronic devices. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0236] The wireless communication module 160 can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0237] In some embodiments, antenna 1 of the electronic device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the electronic device to communicate with networks and other devices via wireless communication technology.

[0238] The display screen 194 is used to display the application's interface, etc. The display screen 194 includes a display panel. In some embodiments, the electronic device may include one or N display screens 194, where N is a positive integer greater than 1.

[0239] The electronic device 100 can perform shooting functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, and an application processor. The ISP is used to process the data fed back by the camera 193.

[0240] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system and software code for at least one application program. The data storage area may store data generated during the use of the electronic device (e.g., images, videos, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, general-purpose flash memory, etc.

[0241] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, images, videos, and other files can be saved on the external memory card.

[0242] Electronic devices can implement audio functions through audio modules 170, speakers 170A, receivers 170B, microphones 170C, headphone jacks 170D, and application processors. Examples include music playback and recording.

[0243] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0244] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or listen to hands-free calls and other external playback scenarios through one or more speakers 170A.

[0245] The receiver 170B, also known as a "handpiece," can be one or more, and is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0246] The microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals.

[0247] The 170D headphone jack is used to connect wired headphones.

[0248] The pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194.

[0249] The gyroscope sensor 180B can be used to determine the motion attitude of an electronic device. In some embodiments, the gyroscope sensor 180B can determine the angular velocity of the electronic device about three axes (i.e., the x, y, and z axes). The gyroscope sensor 180B can be used for image stabilization.

[0250] The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation.

[0251] The magnetic sensor 180D includes a Hall effect sensor. Electronic devices can use the magnetic sensor 180D to detect the opening and closing of a flip cover.

[0252] The 180E accelerometer can detect the magnitude of acceleration in various directions (typically three axes) of electronic devices. When the electronic device is stationary, it can detect the magnitude and direction of gravity.

[0253] The 180F distance sensor is used to measure distance. Electronic devices can measure distance using infrared or laser.

[0254] The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. The electronic device emits infrared light outward through the LED. The electronic device uses the photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that an object is near the electronic device. When insufficient reflected light is detected, the electronic device can determine that no object is near the electronic device.

[0255] An ambient light sensor 180L is used to detect ambient light levels. Electronic devices can adaptively adjust the brightness of the display screen 194 based on the detected ambient light levels.

[0256] The fingerprint sensor 180H is used to collect fingerprints.

[0257] The 180J temperature sensor is used to detect temperature.

[0258] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touch screen." Touch sensor 180K is used to detect touch operations applied to or near it. The touch sensor can then transmit the detected touch operation to the application processor to determine the type of touch event.

[0259] The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire vibration signals from the vibrating bone segments of the human vocal cords.

[0260] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. The electronic device can receive button inputs and generate key signal inputs related to user settings and function control. Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the electronic device.

[0261] It is understood that the components shown in Figure 14 do not constitute a specific limitation on the electronic device. The electronic device in embodiments of the present invention may include more or fewer components than those shown in Figure 14. Furthermore, the combination / connection relationships between the components in Figure 14 can also be adjusted and modified.

[0262] Figure 15 is a schematic diagram of the structure of an electronic device 1500 provided in an embodiment of this application. The electronic device 1500 can be a terminal device or a server as described above. As shown in Figure 15, the electronic device 1500 may include: one or more processors 1501; one or more memories 1502; a communication interface 1503; and one or more computer programs 1504. These devices can be connected via one or more communication buses 1505. The one or more computer programs 1504 are stored in the memory 1502 and configured to be executed by the one or more processors 1501. The one or more computer programs 1504 include instructions. For example, when the electronic device 1500 is a terminal device as described above, the instructions can be used to perform the relevant steps of the terminal device as described in the corresponding embodiments above. When the electronic device 1500 is a server as described above, the instructions can be used to perform the relevant steps of the server as described in the corresponding embodiments above. The communication interface 1503 is used to enable communication between the electronic device 1500 and other devices; for example, the communication interface can be a transceiver.

[0263] In the embodiments provided above, the methods provided by the embodiments of this application are described from the perspective of an electronic device (e.g., a terminal device or a server) as the executing entity. To implement the functions of the methods provided in the embodiments of this application above, the electronic device may include hardware structures and / or software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. Whether a particular function is executed in the form of hardware structures, software modules, or a combination of hardware structures and software modules depends on the specific application and design constraints of the technical solution.

[0264] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)). Where there is no conflict, the solutions of the above embodiments can be used in combination.

[0265] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0266] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0267] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0268] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0269] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope and intent of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and variations.

Claims

1. A compilation method, characterized in that, The system, which includes terminal devices and a server, comprises a code project containing N modules, where N is a positive integer, and none of the N modules have been compiled. The method includes: The terminal device sends a first compilation instruction to the server, the first compilation instruction being used to instruct the compilation of a first module in the code project; The server determines the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, wherein the first dependency relationship is used to describe the dependency relationship between the N modules; The server compiles the first module and the second module.

2. The method according to claim 1, characterized in that, The method further includes: The terminal device modifies the first module; The terminal device sends a second compilation instruction to the server, the second compilation instruction being used to instruct the compilation of the first module; The server determines the third module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; The server compiles the first module and the third module.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The terminal device adds a source code file to the first module; The terminal device sends a third compilation instruction to the server, the third compilation instruction being used to instruct the compilation of the first module; The server determines the fourth module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; The server compiles the first module and the fourth module.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: The server receives the fifth module sent by the terminal device, and the fifth module is a newly added module in the code project; The server adds a dependency relationship between the newly added module and the N modules in the first dependency relationship based on the newly added module.

5. The method according to any one of claims 1-4, characterized in that, Before the server determines the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, the method further includes: The server receives the script file of the first module sent by the terminal device. The script file includes a declaration of the dependency relationship between the first module and other modules in the code project other than the first module. The server generates the first dependency relationship based on the script file of the first module.

6. The method according to any one of claims 1-5, characterized in that, The server determines, based on the first module and the first dependency relationship, a second module in the code project that has a dependency relationship with the first module, including: The server determines, based on the first module and the first dependency, a second module in the code project that has a dependency on the first module, and a sixth module in the code project that has a dependency on the second module; The server compiles the first module and the second module, including: The server compiles the first module, the second module, and the sixth module.

7. The method according to claim 5, characterized in that, The script file of the first module includes type declarations, and the types include at least one of static library files, dynamic library files, or executable files.

8. The method according to any one of claims 1-7, characterized in that, The first module is a static library file.

9. The method according to any one of claims 1-8, characterized in that, The second module in the code project that is determined to have a dependency relationship with the first module includes: It is determined that the first module depends on the second module.

10. The method according to any one of claims 1-9, characterized in that, Before the server compiles the first module and the second module, the method further includes: The terminal device receives a prompt message sent by the server, the prompt message being used to prompt whether to compile the second module; In response to the user's confirmation operation, the terminal device sends a confirmation compilation command to the server.

11. The method according to any one of claims 1-10, characterized in that, The server compiles the first module and the second module, including: The server compiles the source code files in the first module and the second module.

12. A compilation method, characterized in that, Applied to a terminal device, the method includes: The terminal device determines a first module, which is at least one of N modules included in the code project, where N is a positive integer, and none of the N modules have been compiled. The code project is located on a server. The terminal device sends a first compilation instruction to the server. The first compilation instruction is used to trigger the server to determine the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, and to compile the first module and the second module. The first dependency relationship is used to describe the dependency relationship between the N modules.

13. The method according to claim 12, characterized in that, The method further includes: The terminal device modifies the first module; The terminal device sends a second compilation instruction to the server. The second compilation instruction is used to trigger the server to determine the third module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, and to compile the first module and the third module.

14. The method according to claim 12 or 13, characterized in that, The method further includes: The terminal device adds a source code file to the first module; The terminal device sends a third compilation instruction to the server, which triggers the server to determine a fourth module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, and to compile the first module and the fourth module.

15. The method according to any one of claims 12-14, characterized in that, The method further includes: The terminal device sends a fifth module to the server. The fifth module is a newly added module in the code project. The server is used to add a dependency relationship between the newly added module and the N modules in the first dependency relationship based on the newly added module.

16. The method according to any one of claims 12-15, characterized in that, The method further includes: The terminal device sends the script file of the first module to the server. The script file includes a declaration of the dependency relationship between the first module and other modules in the code project besides the first module, so that the server can generate the first dependency relationship based on the script file of the first module.

17. A compilation method, characterized in that, Applied to a server, the server includes a code project comprising N modules, where N is a positive integer, and none of the N modules have been compiled. The method includes: The server receives a first compilation instruction sent by the terminal device, the first compilation instruction being used to instruct the compilation of a first module in the code project; The server determines the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, wherein the first dependency relationship is used to describe the dependency relationship between the N modules; The server compiles the first module and the second module.

18. The method according to claim 17, characterized in that, The method further includes: The server determines that the first module has been modified; The server receives a second compilation instruction sent by the terminal device, the second compilation instruction being used to instruct the compilation of the first module; The server determines the third module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; The server compiles the first module and the third module.

19. The method according to claim 17 or 18, characterized in that, The method further includes: The server determines that a new source code file has been added within the first module; The server receives a third compilation instruction sent by the terminal device, the third compilation instruction being used to instruct the compilation of the first module; The server determines the fourth module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship; The server compiles the first module and the fourth module.

20. The method according to any one of claims 17-19, characterized in that, The method further includes: The server receives the fifth module sent by the terminal device, and the fifth module is a newly added module in the code project; The server adds a dependency relationship between the newly added module and the N modules in the first dependency relationship based on the newly added module.

21. The method according to any one of claims 17-20, characterized in that, Before the server determines the second module in the code project that has a dependency relationship with the first module based on the first module and the first dependency relationship, the method further includes: The server receives the script file of the first module sent by the terminal device. The script file includes a declaration of the dependency relationship between the first module and other modules in the code project other than the first module. The server generates the first dependency relationship based on the script file of the first module.

22. A communication system, characterized in that, include: Terminal device, configured to perform the method as described in any one of claims 12-16; A server for performing the method as described in any one of claims 17-21.

23. A terminal device, characterized in that, Used to perform the steps of the method as described in any one of claims 12-16.

24. A server, characterized in that, Used to perform the steps of the method as described in any one of claims 17-21.

25. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 21.

26. A computer program product, characterized in that, Includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 21.

Images