A method and apparatus for incremental compilation based on source code detection

Abstract

The present invention relates to the field of software development, and particularly to a method and apparatus for incremental compilation based on source code detection. Dependency analysis is performed on the files to be compiled according to file attributes to generate a dependency tree. Each child node in the dependency tree depends on its parent node during compilation, and each node in the dependency tree is a compilation package. The files in each node of the dependency tree are traversed to analyze the modification types of the code. All packages that need to be compiled are found according to the modification types and dependency order, and all packages that need to be compiled are compiled in the dependency order. The present invention minimizes repeated compilation, shortens the compilation time, and reduces the compilation cost. Through dynamic dependency analysis based on the source code, there is no need to set the compilation order and related dependency relationships in advance, avoiding compilation problems caused under the premise of unknown compilation dependencies.

Description

Technical Field

[0001] The present invention relates to the field of software development, and particularly to a method and device for incremental compilation based on source code detection. Background Art

[0002] In the current software development process, for projects with complex functions, usually the code volume is relatively large, there are many modules, and the dependencies are complex. The full-scale compilation time is very long, which affects the project development progress. In order to reduce the compilation duration, currently some compilation tools or project management tools include an incremental compilation function, which only compiles the code packages that have been modified. However, most of the existing incremental compilation tools compile all the modified code packages without distinction, or require manual setting of the dependency relationships of the code files, and the use is relatively complex.

[0003] Taking C++ as an example, incremental compilation can only be achieved by combining with the third-party tool Conan. This solution mainly compiles backward according to the dependency order starting from any package position by calling the command python build.py bc--continue_from packageName. However, the existing functions of this tool still cannot solve the following problems: 1. The optimal number of compilation packages O(1), this submission only affects the last one in the queue, and in the worst case, it starts from the beginning, that is, O(n), and as the number of packages increases, O(n) will increase infinitely, which will lead to a huge increase in compilation time, operation and maintenance costs, etc.; 2. How to confirm which package to start compiling from during integrated operation and maintenance. Although developers or teams can clearly know which packages have changed according to the actual work process, in the entire pipeline of continuous integration and continuous deployment (CI / CD) in project management, since the changed packages cannot be automatically obtained, manual setting is required, which reduces the automation degree of the compilation and packaging process; 3. The problem of repeated compilation. When only one line of code is changed and the position of this package is relatively forward in the dependency order, a large number of subsequent packages need to be compiled, which is a very large overhead and waste for server resources; 4. The compilation dependencies cannot be intelligent and automated. When the dependencies are modified frequently or new dependencies are added, human intervention is required, otherwise problems such as less compilation will occur; 5. The data of incremental compilation cannot be quantified and cannot be combined with systems such as version control.

[0004] In view of this, how to overcome the defects existing in the prior art and solve the phenomenon that the dependency relationship analysis of the existing incremental compilation method is inaccurate and manual setting of compilation dependencies is required is a problem to be solved in this technical field. Summary of the Invention

[0005] In view of the above deficiencies or improvement requirements of the prior art, the present invention solves the problem of low automation in the existing incremental compilation method.

[0006] The embodiments of the present invention adopt the following technical solutions:

[0007] In a first aspect, the present invention provides a method for incremental compilation based on source code detection, specifically: performing dependency analysis on the files to be compiled according to file attributes to generate a dependency tree, where each child node in the dependency tree depends on its parent node during compilation, and each node in the dependency tree is a compilation package; traversing the files in each node of the dependency tree to analyze the modification types of the code; finding all the packages to be compiled according to the modification types and dependency order, and compiling all the packages to be compiled in the dependency order.

[0008] Preferably, generating the dependency tree specifically includes: determining the dependency relationships of each file and compilation package in the project during compilation according to one or more of the project file directory, project configuration file, code dependency relationships, and file attributes; taking the root directory of the project as the root of the tree, and arranging all the compilation packages as a dependency tree according to the dependency relationships.

[0009] Preferably, analyzing the modification types of the code specifically includes: determining the time range when the code changes, and obtaining the file types and code contents that have changed; when the file type that has changed is a code file, performing syntax analysis on the changed code, and judging the modification type according to the syntax type of the modified content.

[0010] Preferably, performing syntax analysis on the changed code specifically includes: extracting the class names, method names, and / or variable name keywords of each line according to the syntax of the code language; comparing the extracted keywords with the class name, method name, and / or variable name templates to judge the syntax type of the modification.

[0011] Preferably, judging the modification type according to the syntax type of the modified content specifically includes: when the syntax type of the modification is a class name and / or class definition, the modification type is a class modification; when the syntax type of the modification is at least one of a method name, return value type, parameter type, and parameter quantity, the modification type is a method modification; when the syntax type of the modification is a variable name and / or variable type, the modification type is a variable modification; when the syntax type of the modification is any one of a comment, parameter name, and code inside the method, the modification type is a general modification.

[0012] Preferably, performing syntax analysis on the changed code further includes: when the code in the file is not a general method, if the function body is modified, the compilation packages affected by it are not compiled.

[0013] Preferably, all packages that need to be compiled are found according to the modification type and dependency order, further including: obtaining the correspondence between the modified compilation packages and files, sorting the file types in each modified compilation package according to the dependency tree, and then sorting the files of each type according to the modification amount.

[0014] Preferably, sorting the files of each type according to the modification amount specifically includes: obtaining the number of modified lines and the total number of lines of each file, and calculating the modification amount of each file according to one or more of the key nature of the modified code, the ratio of the modified lines, and the influence of the modified code; sorting all the modified files according to the modification amount of the files and the file format.

[0015] Preferably, finding all packages that need to be compiled according to the modification type and dependency order specifically includes: determining the packages affected by each modification according to the modification type, and performing single-package compilation on each affected package in sequence according to the dependency order.

[0016] On the other hand, the present invention provides an apparatus for incremental compilation based on source code detection, specifically including: at least one processor and a memory, the at least one processor and the memory are connected through a data bus, the memory stores instructions executable by the at least one processor, and after the instructions are executed by the processor, they are used to complete the method for incremental compilation based on source code detection in the first aspect.

[0017] Compared with the prior art, the beneficial effects of the embodiments of the present invention are as follows: through dependency analysis and code analysis, the code files and compilation packages that have been modified are automatically obtained, as well as their dependency order, and the packages that need to be compiled are automatically compiled in the dependency order according to the modification type and dependency order. The invention starts from the source code, formulates relevant code inspection rules, analyzes the compilation impact brought by code modification, minimizes repeated compilation, shortens the compilation time, and reduces the compilation cost. Through dynamic dependency analysis based on the source code, there is no need to set the compilation order and relevant dependency relationships in advance, avoiding compilation problems caused by unknown compilation dependencies. In addition, the incremental compilation logic can be improved by customizing dependency rules, significantly enhancing the flexibility of incremental compilation. Description of the Drawings

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and those of ordinary skill in the art can also obtain other drawings based on these drawings without creative efforts.

[0019] Figure 1 It is a flowchart of a method for incremental compilation based on source code detection provided by an embodiment of the present invention;

[0020] Figure 2 An instance of a dependency tree used in a certain implementation scenario of a method for incremental compilation based on source code detection provided by an embodiment of the present invention.

[0021] Figure 3 An instance of the directory structure of a project in the actual implementation scenario of a method for incremental compilation based on source code detection provided by an embodiment of the present invention;

[0022] Figure 4 A flowchart of another method for incremental compilation based on source code detection provided by an embodiment of the present invention;

[0023] Figure 5 A schematic structural diagram of a device for incremental compilation based on source code detection provided by an embodiment of the present invention;

[0024] Among them, the reference numerals are as follows:

[0025] 11: Processor; 12: Memory. Detailed implementation manners

[0026] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0027] The present invention is an architecture of a specific functional system. Therefore, in specific embodiments, the functional logical relationships of each structural module are mainly described, and the specific software and hardware implementation manners are not limited.

[0028] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other. The present invention will be described in detail below with reference to the drawings and embodiments.

[0029] Embodiment 1:

[0030] With the continuous expansion of business, the requirements are becoming increasingly complex and huge, the amount of code has increased exponentially, and each compilation takes a huge amount of time, seriously affecting the efficiency of package production and testing. At present, there is no complete and effective incremental compilation technical solution for C++ and Java.

[0031] The method provided in this embodiment is applicable to Java code managed by mvn and C++ code managed by conan. By extracting the code differences before and after modification, analyzing the types of the different lines, determining whether the modified content belongs to changes in method names, class names, return types, input parameter types, or the number of parameters, etc., and confirming whether the packages affected by this modification need to be compiled based on the modification type, and obtaining the incremental compilation scope through source code analysis of the dependency relationship.

[0032] As Figure 1 shown, the specific steps of the incremental compilation method based on source code detection provided by the embodiments of the present invention are as follows:

[0033] Step 101: Perform dependency analysis on the files to be compiled according to file attributes to generate a dependency tree. Each child node in the dependency tree depends on its parent node during compilation, and each node in the dependency tree is a compilation package.

[0034] In this embodiment, the smallest unit of compilation is the smallest compilation package. When performing incremental compilation, it is not necessary to compile all packages, but only the packages affected by the modification, which reduces the number of packages that need to be recompiled and improves the compilation efficiency.

[0035] In the source code, some files or packages have dependencies on other files or packages. For example, when file B references file A through the import or include keyword, file B depends on file A. When file A is modified and needs to be recompiled, file B also needs to be recompiled to avoid conflicts. The modification of A affects B. In this embodiment, for the sake of simplicity, the package affected by this modification is simply referred to as the affected package. For example, if there is a dependency relationship between package A and package B, and package B depends on package A, when package A changes, it may affect package B, and it is necessary to further determine through code analysis whether the modification of package A will indeed cause package B to need to be recompiled.

[0036] In specific implementation, dependency analysis can be performed according to the language characteristics used in the code, or various development tools can be used to obtain the basic dependency relationship. In this embodiment, the dependency relationship is represented by a dependency tree (tree). The root node of the dependency tree is the root directory of the project or project, and each node represents a smallest compilation package. Each compilation package takes the compilation package it depends on as its parent node and serves as the parent node of other compilation packages that depend on itself. For example, package B and package C depend on package A, and package D depends on package B. The generated dependency tree is as Figure 2 shown. Package B and package C are the child nodes of package A, and package D is the child node of package B. Compilation packages without a dependency relationship are located in different branches of the tree structure, and each branch can be arranged in any order. In Figure 2 , package B and package C are sibling nodes and can be arranged in any left and right sibling order. For the convenience of subsequent description and processing, the sequential array obtained by performing a depth traversal on the dependency tree (tree) provided by this embodiment is denoted as Array1. The model is as follows: [package1,package2,package3,……]. The ID, name, or path of the compilation package is saved in the array according to the dependency order. Figure 2The dependency tree can be recorded as [A, B, D, C] or [A, C, B, D]. After arranging in this order, it can ensure that the compilation order of the dependent compilation packages must be ahead. The order of Array1 can be obtained by analysis before each compilation to improve the degree of automation, or it can be maintained by the user through a global variable definition, or adjusted by the user after automatic analysis. The specific usage method can be freely selected. In the scenario where the user maintains or adjusts the order, the user can iterate and organize the project dependencies from the beginning of the project, and synchronously maintain the order of the dependency tree according to the actual coding content during the development process, or customize the compilation order according to actual needs and project characteristics, as long as the position of the package in the array is modified, the flexibility will be higher and the dependency analysis time will be saved.

[0037] In a specific implementation scenario, the code language is Java. There will be only one main pom.xml in each Java project. At the same time, in an actual project, there may be multiple modules, each module corresponds to a directory, and each directory contains the pom.xml of this module. The lower-level directory depends on the upper-level directory. Therefore, by analyzing the directory hierarchy and the pom.xml files in each directory, the dependency relationship of each file and compilation package in the project during compilation can be determined according to one or more of the project file directory, project configuration file, code dependency relationship, and file attributes.

[0038] First, retrieve the pom.xml address in the entire project and mark each pom.xml. It can be recorded through JsonNodej or directly in the array. Taking the Figure 3 project directory as an example: test-project as the top-level directory can be marked as 1. Since there is only one top-level directory in a project, there should be at most one directory marked as 1. In the dependency tree, this directory serves as the root node. Then mark each directory by level. Each digit represents a level. test-project-system can be marked as 1-1, test-project-common can be marked as 1-4, common-core can be marked as 1-4-1, and so on.

[0039] Then sort according to the marks. The sorting principle is to compare bit by bit in turn, and each bit is sorted from small to large. The order after sorting the above marks is: 1, 1-1, 1-4, 1-4-1. Then parse the pom.xml in each module. Taking the above marks as an example: for the pom.xml marked as 1, only need to obtain the <artifactid>test-project< / artifactid> content in it, and replace the above mark 1 with test-project, and then find the <artifactid>test-project-system< / artifactid>Content, and take 1-1est-project-system, and so on, loop and parse until the last child node, loop through the JsonNode, use the root directory of the project as the root of the tree, arrange all compiled packages as a dependency tree according to the dependency relationship, and generate a dependency order list at the same time. For modules without dependency relationships, the sorting is not in any particular order.

[0040] In another specific implementation scenario, the code language is C++. According to the grammar features of C++, dependency relationships can be parsed through pre-compilation directives, header files, namespaces, etc., and establish a dependency tree by analyzing the #include of header files and namespaces in all files of all packages.

[0041] In the existing development environment, complex and large projects usually use project management tools for code management. In the scenarios of using these tools, the dependency tree can also be obtained through the project management tools. For example: for the commonly used Java microservice management tool maven, mvn dependency:list and mvn dependency:tree can be executed; for the commonly used C++ third-party package management tool conan, python build.py la-p PKN can be executed to obtain all package dependencies list and tree.

[0042] Step 102: Traverse the files in each node of the dependency tree and analyze the modification type of the code.

[0043] When modifying the code, different types of modifications affect different compiled packages. For example, if the class name is modified, all the code that uses this class needs to be recompiled, that is, all affected packages need to be recompiled; if only the internal code of the function is modified, only this compiled package needs to be compiled, and there is no need to compile the affected packages; if only the parameter name or comment of the function is modified, none of the packages need to be recompiled.

[0044] In order to reduce the inspection volume and quickly locate whether it is necessary to compile the affected packages, the strategy is to first analyze each changed file in each package, obtain the sorting of the file change amount, and then analyze whether it is necessary to compile the affected packages according to the sorting. In order to further reduce the inspection volume, when analyzing in order, once the compilation rule triggered by a certain file, the subsequent files in this package will no longer be analyzed, but instead continue to analyze the next package.

[0045] In specific implementation, the code paths, code contents, file types (such as.java,.h,.cpp, etc.), and package names before and after the change can be obtained by setting the time and code address, determining the time range during which the code changes, obtaining the file types and code contents that have changed, and obtaining an object array of the package - file name correspondence for this change. For the sake of simplicity in description, the object array is denoted as Array2, and the model is as follows: [{"package2":["xx.h","xxx.cpp"]},{"package3":["aaa.h"]},{"package1":["xx.h","xxc.cpp","zzz.cpp"]},……]. Each file with changes in each compilation package is recorded in the array. To ensure the correct dependency order and enable the files earlier in the dependency relationship to trigger the compilation rules earlier to reduce the number of file analyses, the internal packages in Array2 are sorted according to the dependency relationship in Array1. The result after sorting according to the order of Array1 in step 101 is: [{"package1":["xxx.cpp","xxx.h"]},{"package2":["aaa.h"]},{"package3":["xx.h","zzz.cpp","xxc.cpp"]},……].

[0046] When the file type of the changed file is a code file, syntax analysis is performed on the changed code, and the change type is judged according to the syntax type of the modified content. Starting from the first package in Array2, it is judged whether the file is a file storing a common method package through the code path or other specified constraint conditions. For example, it is agreed that the package name must contain the keyword common, etc. In this embodiment, the file storing common methods is called the common layer. After judgment, corresponding annotation records also need to be made for the file. For example, for a Java language project, it can be recorded in the form of a JsonArray.

[0047] For common layer files, usually all compilation packages will reference them. Therefore, when there are substantial code modifications, it is necessary to re - compile the package where the file is located and all affected packages; when there are non - substantial modifications such as comments and internal variable names, there is no need to re - compile.

[0048] For non-public layer files, modifications may affect other dependent files or may only be internal modifications unrelated to other files. Therefore, it is necessary to judge the keywords and naming rules of related classes, methods, etc. for the changed lines, and determine the scope of influence of this modification according to the modification type. When the code in the file is not a general method, if the function body is modified, the compilation packages affected by it are not compiled. During specific judgment, the keywords are mainly keywords in the development language. For example, public, private, protected, and data types in Java, void, class, and data types in C++. The judgment method can adopt a fuzzy matching algorithm. According to the syntax of the code language, extract the keywords of the class name, method name, and / or variable name for each line, and compare the extracted keywords with the templates of the class name, method name, and / or variable name to judge the syntax type of the modification. Among them, the templates can be predefined according to the development specifications or can be the method names, class names, etc. used in the previous version. If the changed line does not contain keywords, the line is an ordinary line. Through the above method, it can be confirmed whether the changed line is a method name or a class name, or other ordinary lines. After distinguishing the types of changed lines, mark each file. The specific marking method can be defined by yourself in an easy-to-use way. For example: If the content of this change is to add a method, this class is directly marked as MN (method name).

[0049] Step 103: Find all the packages that need to be compiled according to the modification type and the dependency order, and compile all the packages that need to be compiled in the dependency order.

[0050] After judging the modification types of all files, obtain the number of modified lines and the total number of lines for each file. Compared with the original file, all lines with changes except formatting belong to the modified lines. And calculate the change amount for each file. Specifically, set all possible factors affecting the compilation scope as influencing factors, and set a proportion for each influencing factor. The influencing factors include one or more of the key importance of the changed code, the proportion of the changed lines, and the influence of the changed code. In specific implementation, the weight of each influencing factor affecting the change amount can be set according to the degree of influence of the modification, and the weighted comprehensive value of all influencing factors can be calculated. Since the code in the public layer may be referenced by most compilation packages, the key importance of the modified code in the public layer can be set with a higher proportion. To facilitate keyword splitting during syntax analysis and facilitate the statistical calculation of the change amount, the changed lines in the files of each package can be formatted first, deleting unnecessary spaces, line breaks, etc. to make it meet the code development specifications.

[0051] After obtaining the change amount of each file, it is also necessary to obtain the correspondence between the changed compilation packages and files according to the change amount of the files and the file formats, and sort the files in each changed compilation package according to the dependency tree. First, sort by file type, and the sorting order can be in the dependency order. For example: usually, a.cpp file will reference a.h file with the same name. Therefore, the.h file has a higher dependency order and is sorted before the.cpp file. Then, sort the files of each type according to the modification amount, and the files with a larger modification amount are sorted earlier. After sorting, the preliminary sorting result of all files in this submission is recorded as Array3. The final formed Array3 model is as follows: [{"package1":["xx.h","xxx.cpp"]},{"package2":["aaa.h"]},{"package3":["xx.h","xxc.cpp","zzz.cpp"]},……]. The files with changes in each compilation package are recorded in the array in the above order.

[0052] Analyze the sorted files according to the development language, and determine whether the code modification this time only affects the compilation of this package or will affect the compilation of the child node packages according to the modification type, and obtain the packages affected by each modification. Determine whether the packages such as package1, package2, package3... in Array3 need to compile the affected packages. If so, add the affected packages to Array4. For example, package1 affects package11 and package111; package2 does not affect other packages, package3 affects package6 and package7, package4 affects package6 and package10. Then the Array4 model is: [package1,package11,package111,package2,package3,package6,package7,package4,package6,package10]. The array stores the IDs, names, or paths of the compilation packages. In actual implementation, the modification of files with a higher dependency order usually affects all subsequent compilation packages. To reduce the amount of analysis, if the files sorted earlier trigger the rules for compilation-affected packages, the subsequent files will no longer be analyzed.

[0053] The following simply provides the corresponding relationships of the influence scopes of some common modification types in general scenarios. In actual implementation, the corresponding compilation rules can be set according to the specific definitions of the modification types, the characteristics of the code language, the actual architecture of the project, etc.

[0054] (1) When the syntax type of the modification is the class name or class definition, the modification type is a class modification, and all affected packages need to be compiled.

[0055] (2) When at least one of the modified syntax types is method name, return value type, parameter type, or number of parameters, the modification type is method modification, and all affected packages need to be compiled.

[0056] (3) When the modified syntax type is variable name and / or variable type, the modification type is variable modification, and the affected packages need to be modified.

[0057] (4) When the modified syntax type is any one of comments, parameter names, and code inside the method, the modification type is normal modification, and the affected packages are not modified.

[0058] After obtaining the scope of influence, each affected package can be compiled one by one in the dependency order obtained in step 102.

[0059] After steps 101 - 103 provided in this embodiment, through the automatic analysis of project files and code, the dependency order and the scope of modification influence can be obtained, and the compilation packages affected by each modification and the compilation order of the affected packages can be obtained as accurately as possible, so that the number of compilation packages for each incremental compilation is minimized and the compilation order best meets the project requirements.

[0060] In actual implementation, before performing incremental compilation, corresponding parameters also need to be set. The following provides some configuration methods for common parameters. The specific parameter types and values to be configured can be determined according to the development environment and specific project requirements.

[0061] (1) Compilation time: Determine the time range during which the code has changed and obtain the changed code. If the first compilation has not been performed, a full compilation of all compilation packages is carried out.

[0062] (2) Code address: Set the actual code version management address used in the project to obtain the project's code and configuration files. The method provided in this embodiment is compatible with various common code version management tools such as Git and SVN.

[0063] (3) Development language configuration: Set the specific development language used in the project so that corresponding parsing can be performed according to the development language in subsequent steps, reducing unnecessary logical judgment processing.

[0064] After parameter settings, the corresponding steps in steps 101 - 103 can be executed to complete the process of automatically obtaining the dependency order, automatically obtaining the affected packages, and automatic incremental compilation.

[0065] To facilitate project management and the iteration of incremental compilation, the entire pipeline of incremental compilation and CI / CD is combined, as Figure 4As shown, the following steps can be used to complete the incremental compilation process.

[0066] Step 201: Sort all the affected packages to be compiled according to the dependency order.

[0067] To facilitate obtaining the compilation order and further avoid duplicate compilation, remove duplicates from all the package names in Array4 and sort them according to the dependency order in Arrat1. The sorted Array4 model is as follows: [package1,package2,package3,package4,package6,package7,package10,package11,package111]. The ID, name, or path of the compilation package is saved in the array according to the dependency order.

[0068] Step 202: Perform single-package compilation sequentially according to the dependency order of the affected packages.

[0069] According to the development language, enter the source code pom.xml / conanfile.py directory of each package. For Java, mvn can be used for compilation, and for C++, conan can be used for compilation, and record the compilation duration of each package. If the compilation fails, directly return the error code and the detailed error information, which is generally generated by the compilation tool.

[0070] Step 203: Record the changes in this compilation and the affected packages of the compilation, and perform version management on the newly compiled packages.

[0071] In specific implementation, it can be named in the form of package name + timestamp, for example: xxxx-202205051729.jar, and passed into the package management repository. Since there are many ways to process the package after compilation, the present invention only takes passing into the repository as an example. According to needs, detailed data display and log recording can also be performed on this incremental compilation.

[0072] Through steps 201 - 203, the specific incremental management process and the corresponding management and recording functions can be completed. Since the present invention provides services in the form of RestAPI, it can be provided to developers for independent operation, or provided to continuous integration, test operation and maintenance, CICD pipelines, etc. When other compilation systems need it, the interface can be directly called without any adaptation. At the same time, the data of this system can also be provided to other data analysis systems, with strong scalability and a visual interface display.

[0073] The method of incremental compilation based on source code detection provided in this embodiment dynamically analyzes code dependencies through source code, minimizes the compilation unit, diversifies the compilation logic processing, makes the compilation target more explicit, and makes the compilation more dynamic, flexible, and multi-schemed. By formulating rich code inspection rules, the compilation target is made clear, the influence scope of code changes is analyzed to the greatest extent, a large amount of useless compilation is reduced, the compilation time is shortened, the operation and maintenance cost is reduced, and the R & D efficiency is improved. By dynamically analyzing compilation dependencies, the problem of service compilation failure caused by uncompiled downstream services due to modified dependencies is avoided. Through the setting of compilation parameters, full-scale compilation and incremental compilation are automatically switched, making the compilation more flexible. The dynamic analysis and adjustment method in this embodiment has high scalability, is relatively easy to dock with other system services, and causes less transformation to the overall system in the construction of the entire compilation system.

[0074] Furthermore, data such as compilation duration, modified compilation packages, and affected packages during the incremental compilation process can also be stored and displayed in the forms of version management and logs, and cumulatively stored in each compilation. Furthermore, data analysis can also be performed after accumulating a certain amount of data. For example: further analyze how to improve compilation efficiency through compilation duration, analyze the coupling of each piece of code through the impact factor of the modification, and analyze whether there is improper architecture design or whether there are too many bugs caused by insufficient ability of R & D personnel themselves through the modification frequency of each package. Provide data support for improving R & D efficiency, optimizing system architecture, and even personnel assessment.

[0075] Embodiment 2:

[0076] Based on the method of incremental compilation based on source code detection provided in Embodiment 1, in different specific application scenarios, it can also be supplemented and adjusted according to different usage requirements or actual scenarios. The following briefly provides implementation methods in some common development scenarios. In actual implementation, the source code detection and incremental compilation can be completed with reference to the following methods according to the actual needs of the project. For the following technical solutions, one or more technical solutions can be selected and combined with the technical solutions in Embodiment 1 in the case of no conflict.

[0077] In the actual implementation process, there are mainly three common compilation parameters: compilation time, code address, and development language. In a specific implementation scenario, the following specific parameter values can be used.

[0078] 1. Compilation time: set build_time=n. Among them, n can take any number greater than or equal to -1. n=-1 means full-scale compilation, n=0 means obtaining the code updated today, n=1 means the total amount of code updated from yesterday to today, and so on.

[0079] 2. Code address: set code_url = path. Here, path is the address of the project, which can be a local address or a remote address. For example, the project address of the project named "newCode" in svn: http: / / xx.xxx.xx.xx / newCode / newProject.

[0080] 3. Development language configuration: set code_language = language. Here, language represents the type of development language. The possible code languages can be enumerated and defined in advance. For example: Java is 0, C++ is 1, etc.

[0081] In the specific implementation process, the above values can be directly used as the parameters for incremental compilation, or other corresponding parameter types and parameter values can be used according to actual needs and the requirements of the specific development environment.

[0082] In the specific implementation process, the code analysis process in steps 101 and 102 can be completed by referring to the following method. The meanings of some abbreviations mentioned below are as follows: CN (class name): class name; RT (return type): return type; MN (method name): method name; PT (parameter type): parameter type; PN (parameter name): parameter name; PKN (package name): package name.

[0083] (1) The development language is Java.

[0084] Java is a pure object-oriented language. Each class can be regarded as a module, mainly for multi-module microservices. Mainly check the class name, method name, and configuration files such as.yaml and.xml, and match them one by one according to the marked attributes of each file in order of priority. The following priorities are only for reference and can be defined according to actual needs in actual use.

[0085] a: If the file type is.java and the public class CN contained in this line changes, compile the affected package.

[0086] b: If the file type is.java and the line type is public RT MN(PT PN,...), any change other than the change of PN, including the change of the number of parameters, compile the affected package.

[0087] c: If the file type is.java and it is not the above two changes, do not compile the affected package.

[0088] d: If the file type is.yaml,.xml, etc., the impact package will not be compiled.

[0089] e: If comments are added, deleted, or modified, the impact package will not be compiled.

[0090] f: Other compilation rules that require special handling. For example, if a package has its version upgraded in pom.xml, the impact package needs to be compiled in this case. A new compilation rule can be defined. Whenever a version change is detected in pom.xml, the impact package needs to be compiled. When implementing specifically, an enumeration class can be used to define the rule, and then a factory method can be used for processing.

[0091] g: The Feign microservice API needs to be compiled before the calling service. However, there is no dependency between the API and the calling service. Therefore, it is recommended to reference the API in the pom.xml of the calling service.

[0092] Corresponding to the above rules, examples in a specific project are as follows:

[0093] (1) Original: new-project / project-common / project-common-core / src / main / java / com / fiberhome / common / core / web / domain / test.java

[0094] Modified: new-project / project-common / project-common-core / src / main / java / com / fiberhome / common / core / web / domain / testProject.java

[0095] . The change in the file name of the.java file indicates a change in the class name defined in the file. In this case, the class name in the common layer has changed, meeting rule a, and the impacted class needs to be compiled.

[0096] (2) Original: public BoolQueryBuilder queryMsg(IndexEntity index Entity,BoolQueryBuilder mustQuery)throws IOException{}

[0097] Modified: public BoolQueryBuilder queryMsg(IndexEntity indexEntity)throws IOException{}

[0098] This situation meets the condition that the number of parameters changes in case B and requires compilation of the affected class.

[0099] 3. Original: public BoolQueryBuilder queryMsg(IndexEntity indexEntity,BoolQueryBuilder mustQuery)throws IOException{}

[0100] After modification: public BoolQueryBuilder queryMsg(IndexEntity test,BoolQueryBuilder mustQuery)throws IOException{}

[0101] This situation does not meet the conditions of cases A - E and does not require compilation of the affected class.

[0102] 4. Path: new - project / project - admin / src / main / resources / bootstrap.yml

[0103] Original:

[0104] server:

[0105] port:8080

[0106] After modification:

[0107] server:

[0108] port:8081

[0109] This situation modifies the.yml type file, meets the condition of case D, and does not require compilation of the affected class.

[0110] 5. Original:

[0111]

[0112] After modification:

[0113]

[0114]

[0115] This situation only modifies the comments, meets the condition of case E, and does not require compilation of the affected class.

[0116] 6. The record of changes found in a certain commit is as follows:

[0117] 1) Original: new-project / project-admin / src / main / java / com / fiberhome / test.java

[0118] After modification: new-project / project-admin / src / main / java / com / fiberhome / testAdmin.java

[0119] The class name is modified to meet condition a.

[0120] 2) Path: new-project / project-common / src / main / java / com / fiberhome / testCore.java

[0121] Original: public BoolQueryBuilder queryMsg(IndexEntity index,BoolQueryBuilder mustQuery)throws IOException{}

[0122] After modification: public BoolQueryBuilder queryMsg(IndexEntity indexEntity,BoolQueryBuilder mustQuery)throws IOException{}

[0123] The parameter name is modified to meet condition c.

[0124] 3) Path: new-project / project-common / src / main / java / com / fiberhome / testMeg.java

[0125] Original: public BoolQueryBuilder queryMsg(IndexEntity indexEntity,BoolQueryBuilder mustQuery)throws IOException{}

[0126] After modification: public BoolQueryBuilder queryMsgTe(IndexEntity indexEntity,BoolQueryBuilder mustQuery)throws IOException{}

[0127] The method name has been modified to meet condition b.

[0128] Since there are multiple modifications, for improving the retrieval efficiency, priority detection is carried out. According to the priority, first check whether the class name and so on have changed. If so, the detection of other changes in this package can be skipped, and it can be directly determined that the affected package needs to be compiled. As shown in the above example, after detecting the change in 1), directly determine the affected scope according to the rules for meeting condition a, and the modifications in 2) and 3) do not need to be detected and judged for the modification type again.

[0129] (2) The development language is C++.

[0130] C++ supports both object-oriented and procedure-oriented programming. The code structure has many classifications. The same method as that of Java can be adopted to define rules for the changed code lines. The code structure can also be defined at the beginning of the project, dividing the code into a common layer and a business layer, and judging whether each code line is an ordinary line. For the code in the common layer, the keyword "common" can be marked in the path as an identifier. The following priorities are only for reference and can be defined according to actual needs in actual use.

[0131] a: If the file is in the common layer and the line is a comment, the affected package will not be compiled.

[0132] b: If the file is not in the common layer and the line is the code inside the function body, the affected package will not be compiled.

[0133] c: Whether adding, deleting, or modifying comments, regardless of whether it is in the common layer, the affected package will not be compiled.

[0134] d: Other compilation rules that require special handling. For example: for some packages that reference ICE files and need to process the affected package, they need to be defined first in the compilation rules.

[0135] Corresponding to the above rules, examples in specific projects are as follows:

[0136] (1) Original: new-project / project-common / src / testProject.h

[0137] After modification: new-project / project-common / src / testProject1.h

[0138] . The file name of the.h file has changed, indicating that the class name defined in the file has changed, and the affected package needs to be compiled.

[0139] (2) Path: project-common / project-common-core / inclued / testProject.h

[0140] Original:

[0141] / / Split prefix

[0142] int pos = strPrefix.find_last_of(';');

[0143] After modification:

[0144] / / Split prefix by 4 digits

[0145] int pos = strPrefix.find_last_of(';');

[0146] In this case, only the comment is modified, which meets condition a and does not require a compilation impact package. (3) Path: project-admin / src / testProject.cpp

[0147] Original:

[0148]

[0149] After modification:

[0150]

[0151]

[0152] In this case, only the code inside the function is modified, which meets condition b and does not require a compilation impact package.

[0153] Through the implementation method in the specific scenario provided in this embodiment, the code analysis in step 102 and the impact scope judgment in step 103 of the incremental compilation method based on source code detection provided in Embodiment 1 can be completed. By directly performing syntax analysis on the source code to obtain the modification type and formulating corresponding compilation rules for each modification type, the minimum impact scope that needs to be compiled for each modification is determined, avoiding the situation where only modifying the comment requires recompiling all dependent packages during the actual development process, saving compilation time and improving compilation efficiency.

[0154] Embodiment 3:

[0155] Based on the incremental compilation method based on source code detection provided in the above Embodiments 1 to 2, the present invention further provides an apparatus for incremental compilation based on source code detection that can be used to implement the above method, as Figure 5 shown, which is a schematic diagram of the apparatus architecture of an embodiment of the present invention. The apparatus for incremental compilation based on source code detection in this embodiment includes one or more processors 11 and a memory 12. Among them, Figure 5 one processor 11 is taken as an example.

[0156] The processor 11 and the memory 12 can be connected through a bus or other means. Figure 5 Take the connection through the bus as an example.

[0157] The memory 12, as a non-volatile computer-readable storage medium for an incremental compilation method based on source code detection, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the incremental compilation method based on source code detection in Embodiment 1 to Embodiment 2. The processor 11 executes various functional applications and data processing of the device for incremental compilation based on source code detection by running the non-volatile software programs, instructions, and modules stored in the memory 12, that is, implements the incremental compilation method based on source code detection in Embodiment 1 to Embodiment 2.

[0158] The memory 12 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage devices. In some embodiments, the memory 12 may optionally include a memory remotely set relative to the processor 11, and these remote memories can be connected to the processor 11 through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0159] The program instructions / modules are stored in the memory 12 and, when executed by one or more processors 11, execute the incremental compilation method based on source code detection in Embodiment 1 to Embodiment 2 above. For example, execute the Figure 1 and Figure 4 each step shown.

[0160] Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the embodiments can be completed by instructing related hardware through a program, and this program can be stored in a computer-readable storage medium. The storage medium may include: Read Only Memory (ROM), Random Access Memory (RAM), magnetic disk, optical disk, etc.

[0161] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the present invention shall be included in the protection scope of the present invention.

Claims

1. An incremental compilation method based on source code detection, characterized in that: Perform dependency analysis on the files to be compiled according to file attributes to generate a dependency tree. Each child node in the dependency tree depends on its parent node during compilation, and each node in the dependency tree is a compilation package; Traverse the files in each node of the dependency tree to analyze the modification types of the code; Find all the packages that need to be compiled according to the modification type and dependency order, and compile all the packages that need to be compiled in the dependency order; The finding of all the packages that need to be compiled according to the modification type and dependency order further includes: Obtain the correspondence between the compilation packages and files where changes occur, sort the file types in each modified compilation package according to the dependency tree, and then sort the files of each type according to the modification amount; The sorting of the files of each type according to the modification amount includes: obtaining the number of modified lines and the total number of lines of each file, setting weights for each influencing factor affecting the modification amount according to one or more of the criticality of the modified code, the ratio of the number of modified lines, and the impact of the modified code, calculating the weighted comprehensive value of all influencing factors, and calculating the modification amount of each file; sort all the modified files according to the modification amount of the files and the file format.

2. The method for incremental compilation based on source code detection according to claim 1, wherein The generation of the dependency tree specifically includes: Determine the dependency relationship during compilation of each file and compilation package in the project according to one or more of the project file directory, project configuration file, code dependency relationship, and file attributes; Use the root directory of the project as the root of the tree, and arrange all the compilation packages as a dependency tree according to the dependency relationship.

3. The method of incremental compilation based on source code detection according to claim 1, wherein The analysis of the modification type of the code specifically includes: Determine the time range when the code changes, and obtain the file type and code content where changes occur; When the file type where changes occur is a code file, perform syntax analysis on the changed code, and judge the modification type according to the syntax type of the modified content.

4. The method for incremental compilation based on source code detection according to claim 3, wherein The syntax analysis of the changed code specifically includes: Extract the class name, method name, and / or variable name keywords of each line according to the syntax of the code language; Compare the extracted keywords with the class name, method name, and / or variable name templates to judge the syntax type of the modification.

5. The method for incremental compilation based on source code detection according to claim 3, wherein The judgment of the modification type according to the syntax type of the modified content specifically includes: When the syntax type of the modification is the class name and / or class definition, the modification type is class modification; When the syntax type of the modification is at least one of the method name, return value type, parameter type, and parameter quantity, the modification type is method modification; When the syntax type of the modification is the variable name and / or variable type, the modification type is variable modification; When the syntax type of the modification is any one of the comment, parameter name, and code inside the method, the modification type is general modification.

6. The method for incremental compilation based on source code detection according to claim 3, characterized in that The syntax analysis of the changed code further includes: When the code in the file is not a general method, if there is a modification inside the function body, do not compile the compilation packages affected by it.

7. The method of incremental compilation based on source code detection according to claim 1, characterized in that The finding of all the packages that need to be compiled according to the modification type and dependency order specifically includes: Determine the packages affected by each modification according to the modification type, and perform single-package compilation on each affected package in the order of dependencies.

8. An apparatus for incremental compilation based on source code detection, characterized in that: It includes at least one processor and a memory, the at least one processor and the memory are connected through a data bus, the memory stores instructions executable by the at least one processor, and after the instructions are executed by the processor, they are used to complete the method for incremental compilation based on source code detection according to any one of claims 1-7.

Images