GN file automatic generation method and device, electronic equipment and storage medium

By automatically obtaining and processing module and file information in the project directory, identifying dependencies, and generating GN files, it solves the cumbersome and error-prone problems of manually writing GN files, and achieves efficient and accurate GN file generation.

CN119829046APending Publication Date: 2025-04-15SHANGHAI DONGYUAN MICRO INFORMATION TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411879360.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-19
Publication Date
2025-04-15

AI Technical Summary

Technical Problem

In the prior art, manual writing of GN files is complicated to configure and error-prone, and requires high GN language knowledge of developers, resulting in large workload, low efficiency and poor accuracy.

Method used

By traversing the directory of the target project, obtaining module information and file information, identifying the dependencies between modules and modules, files and files, and modules and files, establishing a tree-like data model, and mapping it into the GN file template to generate a GN file.

Benefits of technology

The automatic generation of GN files is realized, which reduces manual intervention, reduces labor costs, improves development efficiency, ensures the accuracy of generated files, and is highly versatile and scalable.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119829046A_ABST
    Figure CN119829046A_ABST
Patent Text Reader

Abstract

According to the GN file automatic generation method and device, the electronic equipment and the storage medium, the GN file can be automatically generated, manual intervention is little, the labor cost is reduced, the development efficiency is improved, human errors can be avoided, it is ensured that the generated GN file is accurate, meanwhile, high universality and expandability are achieved, multiple programming languages and project structures are supported, and the development efficiency is improved. And the requirements of different projects can be met.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of software development, and in particular relates to a method, device, electronic equipment and storage medium for automatically generating a GN file. Background Art

[0002] As software development projects continue to grow in size and complexity, build systems have become critical in managing project dependencies, compilation options, and build rules. GN (Generate Ninja) is a configuration language for generating Ninja build files, which is widely used in large-scale projects such as Chromium and Fuchsia operating systems. GN files describe the build process of a project, including source files, target files, compilation options, and dependencies.

[0003] GN can efficiently manage the project's build process, but writing and maintaining GN files is a tedious and error-prone task for developers, especially when the project is large and the code base is complex.

[0004] In the prior art, developers usually manually write GN file configurations. This manual writing method has the following problems:

[0005] 1. Large workload: For large-scale projects, manually writing GN files requires processing a large number of source files and dependencies, which is time-consuming and laborious.

[0006] 2. Error-prone: It is easy to miss files or make configuration errors during the manual writing process, resulting in build failure or generating incorrect build products.

[0007] 3. It requires developers to have high knowledge of GN language.

[0008] In addition, some developers will write simple scripts to assist in generating some GN files, but these scripts are usually written for specific projects or specific needs and lack versatility and scalability. Summary of the invention

[0009] Based on this, in order to solve the above technical problems, a method, device, electronic device and storage medium for automatically generating a GN file are provided.

[0010] The technical solution adopted by the present invention is as follows:

[0011] As a first aspect of the present invention, a method for automatically generating a GN file is provided, characterized by comprising:

[0012] Traverse the directory of the target project, obtain module information and file information, and identify the dependencies between modules, between files, and between modules. The module information includes the name of the module, the type of the module, and the list of files under the module. The file information includes the name of the file, the path of the file, the type of the file, and other files or modules on which it depends.

[0013] Establishing a data model, storing the acquired module information and file information and the identified dependency relationships in the data model in a tree structure;

[0014] The module information, file information and dependency relationship in the data model are mapped to corresponding positions in the GN file template, and the GN file is generated by rendering.

[0015] As a second aspect of the present invention, there is provided a GN file automatic generation device, characterized in that it comprises:

[0016] A project structure analysis module is used to traverse the directory of the target project, obtain module information and file information, and identify the dependencies between modules, between files, and between modules. The module information includes the name of the module, the type of the module, and the list of files under the module. The file information includes the name of the file, the path of the file, the type of the file, and other files or modules on which it depends.

[0017] A data model building module, used to build a data model, storing the acquired module information and file information and the identified dependency relationship in the data model in a tree structure;

[0018] The GN file generation module is used to map the module information, file information and dependency relationship in the data model to the corresponding position in the GN file template, and render and generate the GN file.

[0019] As a third aspect of the present invention, an electronic device is provided, characterized in that it includes a storage module, the storage module includes instructions loaded and executed by a processor, and when the instructions are executed, the processor executes a GN file automatic generation method according to the first aspect.

[0020] As a fourth aspect of the present invention, a computer-readable storage medium is provided, which stores one or more programs, characterized in that when the one or more programs are executed by a processor, a GN file automatic generation method according to the first aspect is implemented.

[0021] The present invention can automatically generate GN files with less human intervention, reduce labor costs, improve development efficiency, avoid human errors, and ensure that the generated GN files are accurate. At the same time, it has high versatility and scalability, supports multiple programming languages ​​and project structures, and can adapt to the needs of different projects. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments:

[0023] Figure 1 A flowchart of a method for automatically generating a GN file provided by an embodiment of the present invention;

[0024] Figure 2 A schematic diagram of a GN file automatic generation device provided by an embodiment of the present invention;

[0025] Figure 3 A schematic diagram of an electronic device provided by an embodiment of the present invention;

[0026] Figure 4 FIG. 4 is an exemplary relationship dependency diagram of an embodiment of the present invention. DETAILED DESCRIPTION

[0027] The following will illustrate the implementation methods of the present invention in conjunction with the drawings in the specification. It should be noted that the implementation methods involved in this specification are not exhaustive and do not represent the only implementation methods of the present invention. The following corresponding embodiments are only for the purpose of clearly illustrating the invention content of the patent of the present invention, and are not intended to limit its implementation methods. For ordinary technicians in this field, different forms of changes and modifications can be made on the basis of the description of this embodiment. All obvious changes or modifications that belong to the technical concept and invention content of the present invention are also within the scope of protection of the present invention.

[0028] like Figure 1 As shown, the embodiment of the present application provides a method for automatically generating a GN file, comprising:

[0029] S101, traverse the directory of the target project, obtain module information and file information, and identify dependencies between modules, between files, and between modules and files.

[0030] During the project development process, project developers will set up modules and files in the directory. A module refers to a logical unit, which usually contains related functions or components. For example, a module can be a library, a service, or a component of an application. Files refer to specific code files or resource files that constitute the implementation of the module. For example, source code files, header files, configuration files, etc.

[0031] Assume the following project structure:

[0032]

[0033] Among them, my_project is the root directory of the project, moduleA and moduleB are two subdirectories under the root directory, which are two independent modules. a.cpp and ah are the source files and header files under moduleA, b.cpp and bh are the source files and header files under moduleB, a.cpp depends on ah, b.cpp depends on bh, main.cpp is an executable file (executable), which is also an independent module, and it depends on the header files (ah and bh) of the two modules.

[0034] Among them, the module information includes the name of the module, the type of the module (such as library, executable file, etc.) and the file list under the module. The file information includes the name of the file, the path of the file, the type of the file (such as source file, header file, etc.) and other files or modules it depends on.

[0035] In order to visualize the above module information, file information and dependency relationships to developers and help them understand and manage the dependency relationships more intuitively, a corresponding dependency graph can be generated, such as Figure 4 The UML diagram shown.

[0036] In this embodiment, the specific process of identifying the dependency relationship is as follows:

[0037] S11. Analyze the source code of each file in the directory of the target project through a syntax analyzer (such as ANTLR) to build an abstract syntax tree (AST).

[0038] S12. Extract the reference relationships between modules, classes, functions, and files from the abstract syntax tree, and identify all direct and indirect dependencies.

[0039] Through the above identification process, the code structure can be deeply analyzed and the dependencies can be automatically identified, thereby improving efficiency and accuracy.

[0040] S102: Establish a data model, and store the obtained module information and file information and the identified dependency relationship in the data model in a tree structure.

[0041] The data model is used to clearly represent the project's module information, file information, and dependencies.

[0042] In this embodiment, module information, file information, and dependency relationships are stored in the model in an array format, which enables us to clearly identify the in-degree and out-degree of each node and calculate the depth of any node. Thus, we can further determine whether the current dependency relationship needs to be optimized. The specific determination process is as follows:

[0043] S21. Identify the in-degree and out-degree of each node in the data model, and calculate the depth of each node.

[0044] S22. If there is a node whose depth exceeds the maximum depth of the target project directory, the source code corresponding to the node is input into the dependency identification model, and the redundant dependencies and / or circular dependencies existing in the source code are output for the user to modify the source code.

[0045] As in the above example (my_project is the root directory), the maximum depth of the project directory is 3.

[0046] Among them, the dependency identification model can give optimization suggestions while outputting the results. For example, when redundant dependencies are identified, it can point out which dependencies can be removed or merged, etc. When circular dependencies are identified, it can prompt for refactoring, etc. Furthermore, it can also provide optimized dependency graphs and codes, and the developer can choose whether to replace them.

[0047] After optimizing the dependency relationship based on the above process, the accuracy of the dependency relationship can be further improved.

[0048] The dependency identification model uses the ResNet model, which is trained with historical data marked with redundant dependencies and cyclic dependencies. The historical data is as follows:

[0049] 1. Historical project data

[0050] Codebase: Historical project code containing redundant and / or circular dependencies, which can be different commit records in a version control system.

[0051] Dependency Graph: A dependency graph extracted from historical projects.

[0052] Among them, redundant dependencies and circular dependencies are marked, and the marked redundant dependencies and circular dependencies both include specific modules or class pairs, and the modules or class pairs refer to two objects with a dependency relationship.

[0053] Circular Dependency Examples: Flagged circular dependencies, including specific pairs of modules or classes.

[0054] 2. Contextual Data

[0055] Modification history: A record of the modifications of each dependency, reflecting its evolution process, to help the model generate optimized code.

[0056] Performance indicators: Performance data related to dependencies, such as loading time, memory usage, etc. The main function of this data is feature selection, which can help the model identify which code features are related to the accurate identification of dependencies, thereby optimizing the input features of the model.

[0057] S23. Monitor the source code of each file in the directory of the target project. If the source code changes, update the corresponding dependency in the data model in real time, so as to dynamically adapt to the changes in the project, simplify the maintenance process of GN files, and reduce maintenance costs and risks.

[0058] S103: Map the module information, file information and dependency relationship in the data model to the corresponding positions in the GN file template, and render to generate a GN file.

[0059] In this embodiment, the generation of the GN file supports flexible configuration and customization, and the detailed implementation process is described as follows:

[0060] 1. Template definition

[0061] Template language selection: Choose a suitable template engine, such as Jinja2, Handlebars, or Mustache, to support dynamic content insertion.

[0062] Template structure design: Define the basic structure of the GN file, including modules, targets, dependencies, etc., and use placeholders to represent dynamic content.

[0063] 2. Data model mapping

[0064] Data model parsing: Parse module information, file information and dependencies from the data model.

[0065] Data mapping: Map the parsed module information, file information, and dependencies to the corresponding placeholders in the template, for example:

[0066] - Module names are mapped to {{module_name}}

[0067] - File paths are mapped to {{file_path}}

[0068] - Dependency lists are mapped to {{dependencies}}

[0069] 3. Configuration and customization

[0070] Configuration file: Provide a configuration file (such as JSON or YAML format) to allow users to define options for the template, for example:

[0071] - Select the target type to build (library, executable, etc.)

[0072] -Define how dependencies are handled (whether optional dependencies are included, etc.)

[0073] -User customization: Allow users to customize template content according to project requirements, support custom placeholders and logic.

[0074] 4. Template rendering

[0075] Rendering engine: Use the selected template engine to render the template according to the data model and configuration file to generate the final GN file content.

[0076] Dynamic content handling: During the rendering process, handle complex logic, such as conditional statements, loops, etc. to adapt to different project structures.

[0077] 5. Output and verification

[0078] File generation: Output the rendered content to the specified GN file, ensuring that the file path and naming conform to the project specifications.

[0079] Dependency verification: After generating the file, perform dependency verification to ensure that the dependencies in the generated GN file are consistent with the actual project structure.

[0080] 6. Version control and rollback

[0081] Version management: When generating GN files, the version information is recorded to support version control of the generated files.

[0082] Rollback mechanism: Provides a rollback function, allowing users to quickly restore to the previous GN file version when problems are found.

[0083] 7. Documentation and Examples

[0084] Documentation: Write detailed usage documentation to explain how to configure and customize the template.

[0085] Example provision: Provides sample projects and templates to help users get started quickly.

[0086] Based on the above process, high-quality GN files can be quickly generated, greatly improving the efficiency of GN file generation and maintenance.

[0087] As can be seen from the above, the embodiment of the present application provides a method for automatically generating a GN file, which can automatically generate a GN file with less manual intervention, reduce labor costs, improve development efficiency, avoid human errors, and ensure that the generated GN file is accurate.

[0088] At the same time, it is highly versatile and extensible, supports multiple programming languages ​​and project structures, and can adapt to the needs of different projects.

[0089] The following will describe in detail the GN file automatic generation device of one or more embodiments of the present invention. Those skilled in the art will appreciate that these devices can be configured using commercially available hardware components through the steps taught in this solution. Figure 2 A GN file automatic generation device provided by an embodiment of the present invention is shown. Figure 2 As shown, the generating device includes a project structure analyzing module 11 , a data model building module 12 and a GN file generating module 13 .

[0090] The project structure analysis module 11 is used to traverse the directory of the target project, obtain module information and file information, and identify the dependency relationship between modules, between files, and between modules and files.

[0091] During the project development process, project developers will set up modules and files in the directory. A module refers to a logical unit, which usually contains related functions or components. For example, a module can be a library, a service, or a component of an application. Files refer to specific code files or resource files that constitute the implementation of the module. For example, source code files, header files, configuration files, etc.

[0092] Assume the following project structure:

[0093]

[0094] Among them, my_project is the root directory of the project, moduleA and moduleB are two subdirectories under the root directory, which are two independent modules. a.cpp and ah are the source files and header files under moduleA, b.cpp and bh are the source files and header files under moduleB, a.cpp depends on ah, b.cpp depends on bh, and main.cpp is an executable file (executable), which depends on the header files (ah and bh) of the two modules.

[0095] Among them, the module information includes the name of the module, the type of the module (such as library, executable file, etc.) and the file list under the module. The file information includes the name of the file, the path of the file, the type of the file (such as source file, header file, etc.) and other files or modules it depends on.

[0096] In order to visualize the above module information, file information and dependency relationships to developers and help them understand and manage the dependency relationships more intuitively, a corresponding dependency graph can be generated, such as Figure 4The UML diagram shown.

[0097] In this embodiment, the specific process of identifying the dependency relationship is as follows:

[0098] S11. Analyze the source code of each file in the directory of the target project through a syntax analyzer (such as ANTLR) to build an abstract syntax tree (AST).

[0099] S12. Extract the reference relationships between modules, classes, functions, and files from the abstract syntax tree, and identify all direct and indirect dependencies.

[0100] Through the above identification process, the code structure can be deeply analyzed and the dependencies can be automatically identified, thereby improving efficiency and accuracy.

[0101] The data model building module 12 is used to build a data model and store the acquired module information and file information and the identified dependency relationship in the data model in a tree structure.

[0102] The data model is used to clearly represent the project's module information, file information, and dependencies.

[0103] In this embodiment, module information, file information, and dependency relationships are stored in the model in an array format, which enables us to clearly identify the in-degree and out-degree of each node and calculate the depth of any node. Thus, we can further determine whether the current dependency relationship needs to be optimized. The specific determination process is as follows:

[0104] S21. Identify the in-degree and out-degree of each node in the data model, and calculate the depth of each node.

[0105] S22. If there is a node whose depth exceeds the depth of the deepest file, the source code corresponding to the node is input into the dependency recognition model, and the redundant dependencies and / or circular dependencies existing in the source code are output for the user to modify the source code.

[0106] Among them, the dependency identification model can give optimization suggestions while outputting the results. For example, when redundant dependencies are identified, it can point out which dependencies can be removed or merged, etc. When circular dependencies are identified, it can prompt for refactoring, etc. Furthermore, it can also provide optimized dependency graphs and codes, and the developer can choose whether to replace them.

[0107] After optimizing the dependency relationship based on the above process, the accuracy of the dependency relationship can be further improved.

[0108] The dependency identification model uses the ResNet model, which is trained with historical data marked with redundant dependencies and cyclic dependencies. The historical data is as follows:

[0109] 1. Historical project data

[0110] Codebase: Historical project code containing redundant and / or circular dependencies, which can be different commit records in a version control system.

[0111] Dependency Graph: A dependency graph extracted from historical projects.

[0112] Among them, redundant dependencies and circular dependencies are marked, and the marked redundant dependencies and circular dependencies both include specific modules or class pairs, and the modules or class pairs refer to two objects with a dependency relationship.

[0113] Circular Dependency Examples: Flagged circular dependencies, including specific pairs of modules or classes.

[0114] 2. Contextual Data

[0115] Modification history: A record of the modifications of each dependency, reflecting its evolution process, to help the model generate optimized code.

[0116] Performance indicators: Performance data related to dependencies, such as loading time, memory usage, etc. The main function of this data is feature selection, which can help the model identify which code features are related to the accurate identification of dependencies, thereby optimizing the input features of the model.

[0117] S23. Monitor the source code of each file in the directory of the target project. If the source code changes, update the corresponding dependency in the data model in real time, so as to dynamically adapt to the changes in the project, simplify the maintenance process of GN files, and reduce maintenance costs and risks.

[0118] The GN file generation module 13 is used to map the module information, file information and dependency relationship in the data model to the corresponding position in the GN file template, and render and generate the GN file.

[0119] In this embodiment, the generation of the GN file supports flexible configuration and customization, and the detailed implementation process is described as follows:

[0120] 1. Template definition

[0121] Template language selection: Choose a suitable template engine, such as Jinja2, Handlebars, or Mustache, to support dynamic content insertion.

[0122] Template structure design: Define the basic structure of the GN file, including modules, targets, dependencies, etc., and use placeholders to represent dynamic content.

[0123] 2. Data model mapping

[0124] Data model parsing: Parse module information, file information and dependencies from the data model.

[0125] Data mapping: Map the parsed module information, file information, and dependencies to the corresponding placeholders in the template, for example:

[0126] - Module names are mapped to {{module_name}}

[0127] - File paths are mapped to {{file_path}}

[0128] - Dependency lists are mapped to {{dependencies}}

[0129] 3. Configuration and customization

[0130] Configuration file: Provide a configuration file (such as JSON or YAML format) to allow users to define options for the template, for example:

[0131] - Select the target type to build (library, executable, etc.)

[0132] -Define how dependencies are handled (whether optional dependencies are included, etc.)

[0133] -User customization: Allow users to customize template content according to project requirements, support custom placeholders and logic.

[0134] 4. Template rendering

[0135] Rendering engine: Use the selected template engine to render the template according to the data model and configuration file to generate the final GN file content.

[0136] Dynamic content handling: During the rendering process, handle complex logic, such as conditional statements, loops, etc. to adapt to different project structures.

[0137] 5. Output and verification

[0138] File generation: Output the rendered content to the specified GN file, ensuring that the file path and naming conform to the project specifications.

[0139] Dependency verification: After generating the file, perform dependency verification to ensure that the dependencies in the generated GN file are consistent with the actual project structure.

[0140] 6. Version control and rollback

[0141] Version management: When generating GN files, the version information is recorded to support version control of the generated files.

[0142] Rollback mechanism: Provides a rollback function, allowing users to quickly restore to the previous GN file version when problems are found.

[0143] 7. Documentation and Examples

[0144] Documentation: Write detailed usage documentation to explain how to configure and customize the template.

[0145] Example provision: Provides sample projects and templates to help users get started quickly.

[0146] Based on the above process, high-quality GN files can be quickly generated, greatly improving the efficiency of GN file generation and maintenance.

[0147] In summary, the GN file automatic generation device provided in the above embodiment can execute the GN file automatic generation method provided in the above embodiments.

[0148] The same as above concept, Figure 2 The structure of the GN file automatic generation device shown can be implemented as an electronic device. Figure 3 A schematic block diagram of the structure of an electronic device provided by an embodiment of the present invention is shown.

[0149] Exemplarily, the electronic device includes a storage module 21 and a processor 22, the storage module 21 includes instructions loaded and executed by the processor 22, and when the instructions are executed, the processor 22 executes the steps according to various exemplary embodiments of the present invention described in the above-mentioned GN file automatic generation method part of this specification.

[0150] It should be understood that the processor 22 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0151] A computer-readable storage medium is also provided in an embodiment of the present invention. The computer-readable storage medium stores one or more programs. When the one or more programs are executed by a processor, the steps of various exemplary embodiments of the present invention described in the above-mentioned GN file automatic generation method are implemented.

[0152] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable storage medium, which may include a computer-readable storage medium (or a non-transitory medium) and a communication medium (or a temporary medium).

[0153] As is known to those of ordinary skill in the art, the term computer-readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. In addition, it is known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium.

[0154] Exemplarily, the computer-readable storage medium may be an internal storage unit of the electronic device of the aforementioned embodiment, such as a hard disk or memory of the electronic device. The computer-readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart memory card (SmartMediaCard, SMC), a secure digital (SecureDigital, SD) card, a flash memory card (FlashCard), etc. equipped on the electronic device.

[0155] The electronic device and computer-readable storage medium provided in the aforementioned embodiments can automatically generate GN files with less manual intervention, thus reducing labor costs, improving development efficiency, and avoiding human errors, thereby ensuring that the generated GN files are accurate.

[0156] At the same time, it is highly versatile and extensible, supports multiple programming languages ​​and project structures, and can adapt to the needs of different projects.

[0157] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for automatically generating a GN file, characterized in that: include: Traverse the directory of the target project, obtain module information and file information, and identify the dependencies between modules, between files, and between modules. The module information includes the name of the module, the type of the module, and the list of files under the module. The file information includes the name of the file, the path of the file, the type of the file, and other files or modules on which it depends. Establishing a data model, storing the acquired module information and file information and the identified dependency relationships in the data model in a tree structure; The module information, file information and dependency relationship in the data model are mapped to corresponding positions in the GN file template, and the GN file is generated by rendering.

2. The method for automatically generating a GN file according to claim 1, characterized in that: The identification of dependencies between modules, between files, and between modules and files further includes: Analyze the source code of each file in the directory of the target project through a syntax analyzer to construct an abstract syntax tree; The reference relationships between modules, classes, functions and files are extracted from the abstract syntax tree, and all direct and indirect dependencies are identified.

3. The method for automatically generating a GN file according to claim 2, characterized in that: The grammar analyzer adopts ANTLR grammar analyzer.

4. The method for automatically generating a GN file according to claim 1, characterized in that: Also includes: Identify the in-degree and out-degree of each node in the data model and calculate the depth of each node; If there is a node whose depth exceeds the depth of the deepest file, the source code corresponding to the node is input into the dependency recognition model, and the redundant dependencies and / or circular dependencies existing in the source code are output, so that the user can modify the source code; The source code of each file in the directory of the target project is monitored, and if the source code changes, the corresponding dependency relationship in the data model is updated in real time.

5. A method for automatically generating a GN file according to claim 4, characterized in that: The dependency identification model is trained by historical data marked with redundant dependencies and circular dependencies.

6. A GN file automatic generation device, characterized in that: include: A project structure analysis module is used to traverse the directory of the target project, obtain module information and file information, and identify the dependencies between modules, between files, and between modules. The module information includes the name of the module, the type of the module, and the list of files under the module. The file information includes the name of the file, the path of the file, the type of the file, and other files or modules on which it depends. A data model building module, used to build a data model, storing the acquired module information and file information and the identified dependency relationship in the data model in a tree structure; The GN file generation module is used to map the module information, file information and dependency relationship in the data model to the corresponding position in the GN file template, and render and generate the GN file.

7. An electronic device, characterized in that: The invention comprises a storage module, wherein the storage module comprises instructions loaded and executed by a processor, and when the instructions are executed, the processor executes a method for automatically generating a GN file according to any one of claims 1 to 5.

8. A computer-readable storage medium storing one or more programs, characterized in that: When the one or more programs are executed by a processor, the method for automatically generating a GN file according to any one of claims 1 to 5 is implemented.