Method for generating build files in compilation based on simulation modeling language and application thereof

Abstract

Disclosed are a method for generating a build file in a simulation modeling language-based compiling process and an application thereof. The method comprises: separately parsing each first source code file based on a simulation modeling language to obtain compiling dependency relationship information among the first source code files; determining the file name and storage path of each second source code file based on a general programming language after translation; establishing a global compiling dependency graph according to the compiling dependency relationship information and the file name and storage path of the second source code file; determining a node that needs to be replaced in the global compiling dependency graph according to the correspondence between a third-party library source code file based on a general programming language and a library source code file based on a simulation modeling language, and updating the corresponding node in the global compiling dependency graph by using the third-party library source code file and its storage path; and generating a build file in a general programming language according to the updated global compiling dependency graph. The present disclosure is conducive to improving the generation efficiency and accuracy of the build file.

Description

Technical Field

[0001] This disclosure relates to the field of simulation modeling technology, and in particular to a method for automatically generating build files during the compilation process of a simulation modeling language, a device for automatically generating build files during the compilation process of a simulation modeling language, a storage medium, and an electronic device. Background Technology

[0002] Simulation modeling languages ​​(such as SimScript) are programming languages ​​specifically designed for simulation modeling. Because they have built-in core simulation concepts (such as simulation scheduling entities, events, resources, and time), syntax that fits business scenarios, and a focus on model description, simulation modeling languages ​​offer advantages such as high modeling efficiency, low modeling threshold (allowing even non-professional programmers to quickly build simulation models), and clear simulation logic.

[0003] However, since simulation modeling languages ​​are usually interpreted simulation languages, meaning they are parsed and run simultaneously without a pre-compilation process to convert the program into machine code, the running speed of simulation modeling language programs is usually lower than that of general programming languages ​​(such as C++). This is especially true when the simulation model is large in scale, where the slow running speed of simulation modeling language programs becomes particularly noticeable and may even cause stuttering.

[0004] To improve the execution speed of simulation modeling language programs, a compilation technique can be employed that first converts the simulation modeling language program into a general-purpose programming language (such as C++), and then generates machine code from the converted general-purpose programming language program. This allows the compiled code to be executed directly at runtime. How to improve simulation execution speed while ensuring the accuracy of the compilation results is a technically important issue. Summary of the Invention

[0005] To address the aforementioned technical problems, this disclosure is proposed. Embodiments of this disclosure provide a method for automatically generating build files during the compilation process of a simulation modeling language, an apparatus for automatically generating build files during the compilation process of a simulation modeling language, a storage medium, and an electronic device.

[0006] According to a first aspect of the present disclosure, a method for automatically generating build files during the compilation process of a simulation modeling language is provided. The method includes: parsing each first source code file based on the simulation modeling language to obtain compilation dependency information between different first source code files; determining the filenames and storage paths of each second source code file based on a general-purpose programming language after translation, according to the filenames of the first source code files and the translation file naming rules; establishing a global compilation dependency graph based on the compilation dependency information and the filenames and storage paths of the second source code files; wherein, nodes in the global compilation dependency graph represent the filenames and storage paths of the second source code files, and directed edges in the global compilation dependency graph represent the compilation dependencies of nodes located at the starting end of the edge and nodes located at the pointing end of the edge; determining the nodes in the global compilation dependency graph that need to be replaced based on the correspondence between third-party library source code files based on the general-purpose programming language and library source code files based on the simulation modeling language, and updating the corresponding nodes in the global compilation dependency graph using the third-party library source code files and their storage paths; and generating a build file for the general-purpose programming language based on the updated global compilation dependency graph.

[0007] According to a second aspect of the present disclosure, an automatic build file generation device based on the compilation process of a simulation modeling language is provided. The device includes: a compilation dependency determination module, configured to parse each first source code file based on the simulation modeling language to obtain compilation dependency information between different first source code files; a translation result determination module, configured to determine the filenames and storage paths of each translated second source code file based on a general programming language according to the filenames of the first source code files and translation file naming rules; and a dependency graph establishment module, configured to establish a global compilation dependency graph based on the compilation dependency information and the filenames and storage paths of the second source code files. A dependency graph; wherein, nodes in the global compilation dependency graph represent the filenames and storage paths of the second source code files, and directed edges in the global compilation dependency graph represent the compilation dependencies of the node at the starting end of the edge on the node at the pointing end of the edge; a node update module, used to determine the nodes in the global compilation dependency graph that need to be replaced based on the correspondence between the source code files of the third-party library based on the general programming language and the source code files of the library based on the simulation modeling language, and update the corresponding nodes in the global compilation dependency graph using the third-party library source code files and their storage paths; a build file generation module, used to generate a build file for the general programming language based on the updated global compilation dependency graph.

[0008] According to a third aspect of the present disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program for implementing any of the methods described above.

[0009] According to a fourth aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement any of the methods described above.

[0010] The automatic generation method, apparatus, storage medium, and electronic device for build files in the compilation process of a simulation modeling language provided in the embodiments of this disclosure can automatically and comprehensively obtain the compilation dependency information between all first source code files by parsing each first source code file based on the simulation modeling language. Since there are usually corresponding transpiled file naming rules between the first and second source code files (such as keeping the filename body unchanged), this disclosure can utilize these transpiled file naming rules to accurately and comprehensively obtain the filenames and storage paths of all second source code files. That is, it can know the corresponding second source code file and its storage path for each first source code file, thus obtaining the compilation dependency information between the second source code files. This disclosure allows for the convenient generation of a global compilation dependency graph based on the second source code file. For third-party library source code files introduced into the simulation system, this disclosure utilizes the correspondence between third-party library source code files based on a general-purpose programming language and library source code files based on a simulation modeling language to replace corresponding nodes in the global compilation dependency graph. This integrates the third-party library source code files into the global compilation dependency graph. When generating a build file in a general-purpose programming language using the updated global compilation dependency graph, the build file automatically describes the compilation order of all source code files involved in the simulation system. Furthermore, it effectively avoids information omissions and errors that are prone to occur during manual build file creation (especially when the first source code file is numerous). Therefore, the technical solution provided by this disclosure improves the automation level of build file generation and helps avoid introducing human errors during the build file generation process, thereby improving the efficiency and accuracy of build file generation.

[0011] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0012] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 This is a flowchart of an embodiment of the automatic generation method for build files during the compilation process of a simulation modeling language disclosed herein;

[0014] Figure 2 This is a schematic diagram of an embodiment of the automatic build file generation device based on the compilation process of a simulation modeling language disclosed herein.

[0015] Figure 3 This is a structural diagram of an electronic device provided in an exemplary embodiment of this disclosure. Detailed Implementation

[0016] Example embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure, and it should be understood that this disclosure is not limited to the example embodiments described herein.

[0017] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0018] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0019] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0020] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship.

[0021] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0022] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0023] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0024] The embodiments of this disclosure can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, or servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems, etc.

[0025] This disclosure outlines

[0026] In developing this disclosure, the inventors discovered that current transpilers for converting simulation modeling language (e.g., SimScript) code into general-purpose programming language (e.g., C++) code typically focus on parsing the simulation modeling language code and converting its statements into general-purpose programming language statements based on the parsing results. However, in practical applications, converting the translated general-purpose programming language code into executable code often requires the use of a build file (e.g., a makefile). A build file (e.g., a makefile) defines the compilation rules, compilation order, and library linking parameters for the source code of a general-purpose programming language. The build file can be used by tools (e.g., the make tool) to drive the compilation and linking tools in the general-purpose programming language to automatically build the project and form executable code. For example, by executing the make command, the compiler performs the corresponding compilation operations based on the build file. Currently, for translated general-purpose programming language programs, build files are usually created manually by users. The workload of creating build files increases with the number of translated general-purpose programming language program code files. The complex dependencies between program code files further increase the workload of creating build files and are prone to human errors, which can lead to abnormalities in the process of generating executable code and failure to generate executable code.

[0027] As can be seen from the above description, if an implementation method for automatically creating build files can be provided, it will not only help reduce the workload of users and improve the efficiency of creating build files, but also help avoid human errors in the process of creating build files, improve the accuracy of build files, and thus help increase the success rate of generating executable code.

[0028] Exemplary methods

[0029] Figure 1This is a flowchart of an embodiment of the automatic generation method for build files during the compilation process of a simulation modeling language provided in this disclosure. Figure 1 The method shown includes steps S100, S101, S102, S103, and S104. The following describes... Figure 1 Each step in the process will be explained separately.

[0030] S100. Parse each of the first source code files based on the simulation modeling language to obtain the compilation dependency information between different first source code files.

[0031] The simulation modeling language in this disclosure can be SimScript, etc., in the field of discrete event simulation. When the simulation modeling language is SimScript, the first source code file based on the simulation modeling language refers to a public declaration file / interface file written in SimScript with the .sim extension or an implementation file with the _i.sim extension. That is, a module in SimScript typically includes two files: module_name.sim (public declaration file / interface file) and module_name.sim (implementation file). For example, the first source code files in SimScript include: main.sim, main_i.sim, event.sim, event_i.sim, agent.sim, agent_i.sim, model.sim, and model_i.sim, etc. This disclosure does not limit the specific form of the first source code file.

[0032] The first source code files based on the simulation modeling language in this disclosure can be stored in the same storage path or distributed across multiple storage paths. This disclosure can obtain all the first source code files based on the simulation modeling language by scanning the files in a preset storage path. Alternatively, this disclosure can also obtain all the first source code files based on the simulation modeling language by scanning each filename in a preset filename list one by one.

[0033] The parsing of the first source code file in this disclosure can be considered as: identifying specific statements in the first source code file that are related to file compilation dependencies, and obtaining compilation dependency information between different first source code files from the identified specific statements. Specifically, this disclosure can parse each first source code file statement by statement, determine the specific statements in each first source code file that are related to file compilation dependencies from the parsing results, and then obtain the compilation dependency information between different first source code files by performing file compilation dependency extraction processing on the specific statements. The parsing of the first source code file in this disclosure can be achieved through syntax analysis and semantic analysis, and this disclosure does not limit the specific implementation process of parsing the first source code file.

[0034] The compilation dependency information in this disclosure can be considered as information used to reflect the compilation order of different first source code files. For example, if the compilation dependency information is: first source code file A depends on first source code file B, it means that first source code file B is the dependent file, and first source code file B should be compiled before first source code file A.

[0035] In one example, a specific statement in this disclosure may include a file import statement, that is, parsing a first source code file to identify file import statements in the first source code file, and performing grammar rule analysis on the identified file import statements, so as to know the compilation dependency relationship between two first source code files from the grammar rule analysis results.

[0036] In one example, when the simulation modeling language is SimScript, the file inclusion statement can be an include statement. A more specific example assumes there are three source code files: main.sim (main program module), agent.sim (entity module), and common.sim (common utility module), and main.sim includes the following statements:

[0037] include "agent.sim"

[0038] include "common.sim"

[0039] MAIN

[0040] CREATE Agent a

[0041] CALL a.initialize()

[0042] END

[0043] The configuration of common.sim includes the following statements:

[0044] PREAMBLE

[0045] ROUTINE log_message(text)

[0046] END

[0047] ROUTINE log_message(text)

[0048] PRINT text

[0049] END

[0050] Configure agent.sim with the following statements:

[0051] include "common.sim"

[0052] PREAMBLE

[0053] ENTITY Agent

[0054] ATTRIBUTES name, id

[0055] END

[0056] ROUTINE Agent::initialize()

[0057] END

[0058] ROUTINE Agent::initialize()

[0059] CALL log_message("Agent initialized")

[0060] END

[0061] When main.sim is the current file, this disclosure parses the current file main.sim statement by statement. When the first statement mentioned above is parsed in the current file main.sim, the compilation dependency information of the current file main.sim on agent.sim can be obtained (i.e., the compilation of main.sim depends on the compilation of agent.sim); when the second statement mentioned above is parsed in the current file main.sim, the compilation dependency information of the current file main.sim on common.sim can be obtained (i.e., the compilation of main.sim depends on the compilation of common.sim).

[0062] With common.sim as the current file, this disclosure parses the current file common.sim statement by statement. Since the current file common.sim does not contain any include statements, it can be determined that the current file common.sim has no compilation dependency information with main.sim and agent.sim.

[0063] When agent.sim is the current file, this disclosure parses the current file agent.sim statement by statement. When the first statement "include "common.sim" in the current file agent.sim is parsed, the compilation dependency information of the current file agent.sim on common.sim can be obtained (that is, the compilation of agent.sim depends on the compilation of common.sim).

[0064] In one example, a specific statement in this disclosure may include a module import statement, that is, parsing a first source code file to identify module import statements in the first source code file, and performing grammar rule analysis on the identified module import statements, so as to know the compilation dependency relationship between two first source code files from the grammar rule analysis results.

[0065] In one example, when the simulation modeling language is SimScript, the module import statement can be an import statement. A more specific example assumes there are three source code files: the main program module `main.sim`, the entity module `agent.sim`, and the common utility module `common.sim`, with `main.sim` containing the following statements:

[0066] import "agent.sim"

[0067] import "common.sim"

[0068] MAIN

[0069] CREATE Agent a

[0070] CALL a.initialize()

[0071] END

[0072] The configuration of common.sim includes the following statements:

[0073] PREAMBLE

[0074] ROUTINE log_message(text)

[0075] END

[0076] ROUTINE log_message(text)

[0077] PRINT text

[0078] END

[0079] Configure agent.sim with the following statements:

[0080] import "common.sim"

[0081] PREAMBLE

[0082] ENTITY Agent

[0083] ATTRIBUTES name, id

[0084] END

[0085] ROUTINE Agent::initialize()

[0086] END

[0087] ROUTINE Agent::initialize()

[0088] CALL log_message("Agent initialized")

[0089] END

[0090] When main.sim is the current file, this disclosure parses the current file main.sim statement by statement. When the first statement mentioned above is parsed in the current file main.sim, the compilation dependency information of the current file main.sim on agent.sim can be obtained (i.e., the compilation of main.sim depends on the compilation of agent.sim); when the second statement mentioned above is parsed in the current file main.sim, the compilation dependency information of the current file main.sim on common.sim can be obtained (i.e., the compilation of main.sim depends on the compilation of common.sim).

[0091] With common.sim as the current file, this disclosure performs a statement-by-statement parsing of the current file common.sim. Since the current file common.sim does not contain any import statements, it can be determined that the current file common.sim has no compilation dependency information with main.sim and agent.sim.

[0092] When agent.sim is the current file, this disclosure parses the current file agent.sim statement by statement. When the first statement import "common.sim" in the current file agent.sim is parsed, the compilation dependency information of the current file agent.sim on common.sim can be obtained (that is, the compilation of agent.sim depends on the compilation of common.sim).

[0093] By parsing the file import statements and module import statements in the first source code file, the compilation dependencies between files can be analyzed quickly, accurately, and comprehensively without the need for manual analysis. This not only provides reliable basic information for the establishment of a global compilation dependency graph, but also facilitates compatibility with different versions of simulation modeling language programs.

[0094] In one example, specific statements in this disclosure may include function call statements. This involves parsing a first source code file to identify function call statements within it, and performing grammar rule analysis on the identified function call statements. The analysis results reveal the function to be called by the current file, allowing the determination of whether the file defining the function is the current file (e.g., searching for matching key-value pairs in the corresponding function definition dictionary using the function identifier as the key, and determining whether the file in the matching key-value pair is the current file). If it is not the current file, the function is considered a cross-file function call, and the compilation dependency between the two first source code files (i.e., the compilation dependency between the current file and the file defining the function) can be obtained. If it is the current file, the function is considered an intra-file function call, and the compilation dependency between the two first source code files cannot be obtained. As described above, a cross-file function call statement in this disclosure refers to a source code file containing a function (including routine) call statement, where the function called by the function call statement must be defined in another source code file.

[0095] In one example, cross-file function call statements in this disclosure may include function execution statements and entity method call statements. Function execution statements can refer to executable statements used to call and execute defined global functions (routines), and can also be considered general function call statements. Entity method call statements can refer to executable statements used to call and execute member methods (for example) of a specific entity (object), and can also be considered more complex and advanced CALL statements that require parsing class structures.

[0096] In one example, when the simulation modeling language is SimScript, the function execution statement can be a regular CALL statement. A more specific example assumes there are two source code files: the main program module `main.sim` and the entity module `agent.sim`, with `main.sim` containing the following statements:

[0097] import "agent.sim"

[0098] MAIN

[0099] CREATE Agent a

[0100] a.name = "test_agent"

[0101] a.id = 1

[0102] CALL log_agent_status(a)

[0103] END

[0104] Configure agent.sim with the following statements:

[0105] PREAMBLE

[0106] ENTITY Agent

[0107] ATTRIBUTES name, id

[0108] END

[0109] ROUTINE log_agent_status(a)

[0110] END

[0111] ROUTINE log_agent_status(a)

[0112] PRINT "Agent " || a.name || " (ID: " || a.id || ") is ready"

[0113] END

[0114] With main.sim as the current file, this disclosure performs statement-by-statement parsing on the current file main.sim. When the CALL statement in the current file main.sim is parsed, it can be determined that the statement is a normal CALL statement. By continuing to find the definition location of the function log_agent_status(), it can be found that the function log_agent_status() is a global function defined in agent.sim. Since agent.sim and the current file main.sim are two different files, it is determined that the statement is a cross-file function call statement, and the compilation dependency information of the current file main.sim on agent.sim is obtained (i.e., the compilation of main.sim depends on the compilation of agent.sim).

[0115] With agent.sim as the current file, this disclosure performs statement-by-statement parsing on the current file agent.sim. Since no function call statements were successfully obtained, it is determined that the current file does not contain cross-file function call statements, that is, the compilation of agent.sim does not depend on other files.

[0116] In one example, when the simulation modeling language is SimScript, function execution statements can be entity method call statements. A more specific example assumes two source code files: the main program module `main.sim` and the entity module `agent.sim`, with `main.sim` containing the following statements:

[0117] import "agent.sim"

[0118] MAIN

[0119] CREATE Agent

[0120] CALL agent.initialize()

[0121] END

[0122] Configure agent.sim with the following statements:

[0123] PREAMBLE

[0124] ENTITY Agent

[0125] ATTRIBUTES name, id

[0126] END

[0127] ROUTINE Agent::initialize()

[0128] END

[0129] ROUTINE Agent::initialize()

[0130] PRINT "Agent initialized successfully"

[0131] END

[0132] With main.sim as the current file, this disclosure performs statement-by-statement parsing of the current file main.sim. When the CALL statement in the current file main.sim is parsed, it can be determined that the statement is an entity method call statement. agent is an instance of the agent entity, and initialize() is a member method of the agent entity. By continuing to search, it can be found that the definition of the agent entity and the implementation of the initialize() member method are both located in the agent.sim file. Since agent.sim and the current file main.sim are two different files, this statement is determined to be a cross-file function call statement, and the compilation dependency information of the current file main.sim on agent.sim is obtained (i.e., the compilation of main.sim depends on the compilation of agent.sim).

[0133] By parsing the cross-file function call statements in the first source code file, the implicit compilation dependencies contained in the file can be automatically analyzed without the need for manual analysis of the compilation dependencies between files. This helps to avoid the phenomenon of incomplete compilation dependency information due to the lack of explicit import statements, thereby making the basic information for building a global compilation dependency graph more complete and the compilation dependency analysis more complete and accurate.

[0134] S101. Based on the filenames of the first source code files and the naming rules for the translated files, determine the filenames and storage paths of the translated second source code files based on the general programming language.

[0135] The translation file naming rules in this disclosure typically refer to the mapping rules between the filenames of source code files based on simulation modeling languages ​​and the filenames of source code files based on general-purpose programming languages. The translation file naming rules in this disclosure are usually related to the type of the first source code file. Specifically, this disclosure can set a mapping rule for each type of first source code file. Several file types and their mapping rules are listed below:

[0136] The first mapping rule, for a first source code file containing public declarations (i.e., a first source code file of the complete module source file type), will generate two second source code files after translation: a header file and a source file. This disclosure can keep the main filename of the first source code file unchanged, only changing the filename suffix of the first source code file to the header file suffix and the source file suffix. That is to say, the difference between the filenames of the translated header file and the source file is that their suffixes are different. For example, agent.sim is a first source code file containing public declarations, and the two translated files are agent.h and agent.cpp. Specifically, the PREAMBLE block (interface declaration) in agent.sim is translated into agent.h, while the ROUTINE implementation (i.e., logic code) in agent.sim is translated into agent.cpp.

[0137] The second mapping rule, for the first source code file of the interface / declaration type (i.e. the first source code file used for global declaration, also known as the global declaration file), will generate a file (i.e., a header file) after translation. This disclosure can keep the main file name of the first source code file unchanged, and only change the file name suffix of the first source code file to the suffix of the header file. For example, agent.sim is a global declaration file, and the translated file name can be agent.h.

[0138] The third mapping rule is that for the first source code file of the method / implementation type (i.e., the method / implementation file in the simulation modeling language), a file will be generated after translation. This disclosure can keep the main file name of the first source code file unchanged, and only change the file name suffix of the first source code file to the suffix of the source file. For example, if agent.sim is the method / implementation file, the translated file name can be agent.cpp.

[0139] The fourth mapping rule is that for the first source code file of the main program type (i.e. the main program file in the simulation modeling language), a file will be generated after translation. This disclosure can keep the main file name of the first source code file unchanged, and only change the file name suffix of the first source code file to the suffix of the source file. For example, if main.sim is the main program file, the translated file name can be main.cpp.

[0140] It should be noted that the mapping rules listed above are only a general implementation method. Users can set corresponding mapping rules according to their actual needs. For example, the translated file name can contain a fixed prefix. This disclosure does not limit the specific implementation method of the mapping rules.

[0141] The storage paths of the translated second source code files based on the general-purpose programming language in this disclosure may include local storage paths or network-based storage paths (such as cloud storage paths or server-based storage paths). The storage paths of the second source code files are usually different from those of the first source code files, and they may be related to the storage paths of the first source code files; that is, there may be mapping rules between the storage paths of the second and first source code files. For example, if the storage path of the first source code file is sim / agent / , then the storage path of the second source code file could be src / agent / . The storage path of the second source code files may also be determined according to a pre-set default path. The mapping rules or pre-set default paths for the storage paths of the second source code files can also be set in the aforementioned naming rules.

[0142] This disclosure sets corresponding mapping rules for different types of first source code files. While ensuring a clear correspondence between files based on simulation modeling languages ​​and files based on general programming languages, it can effectively adapt to the engineering specifications of separation of declaration and implementation in general programming languages. This facilitates accurate positioning of the translated files, which not only helps to accurately form a global compilation dependency graph using the translated second source code files, but also enables the technical solution of this disclosure to cover a variety of application scenarios using different types of files, thereby improving the applicability of the technical solution of this disclosure.

[0143] In one example, the filename and storage path of the second source code file based on the general-purpose programming language, determined by the transpiled file naming rules, theoretically exist. This disclosure ensures that the determined second source code file is indeed stored in the determined storage path, and not merely exists in the theory derived from the mapping rules. If a second source code file only exists in the theory derived from the mapping rules, it cannot participate in the global compilation dependency graph establishment process because it does not actually exist. This helps avoid the introduction of invalid dependencies, ensures the accuracy of the global compilation dependency graph, and further helps ensure the robustness of the system formed by the transpiled program code based on the general-purpose programming language. This disclosure can use file search technology to ensure that the corresponding second source code file is indeed stored in the storage path derived from the mapping rules in this step. A specific example is given below to illustrate this.

[0144] In a specific example, for any first source code file, after determining the filename and storage path of the second source code file based on the filename of the first source code file and the naming rules for the transpiled file, this disclosure can use the filename to be searched as the filename to be searched, and perform a file search operation within a certain storage range using the filename to be searched. For example, perform a file search operation in all storage paths of the local device; or, for another example, perform a file search operation in a specified path of the local device (i.e., the storage path derived based on the aforementioned mapping rules); or, for yet another example, perform a file search operation in all storage paths of a specified other device; or, for yet another example, perform a file search operation in a specified path of a specified other device; when the file search operation is completed and the file search result is obtained, the current file search result should be... The file search operation is evaluated based on its results. If the file search successfully finds the filename in the storage path derived from the mapping rules, the search is successful, confirming that the corresponding second source code file is indeed stored in the storage path derived from the mapping rules, and this second source code file can participate in the establishment of the global compilation dependency graph. If the file search fails to find the filename in the storage path derived from the mapping rules, the search fails, confirming that the corresponding second source code file is not stored in the storage path derived from the mapping rules, and this second source code file cannot participate in the establishment of the global compilation dependency graph. In this case, an error message is generated to prompt the user to verify the existence of the second source code file. By utilizing file search technology, it is easy and convenient to determine whether the corresponding second source code file is stored in the storage path derived from the mapping rules. Since file search operations can be executed in parallel and have very low overhead, this disclosure can ensure the accuracy of the subsequent global compilation dependency graph without affecting the performance of building the build file. In addition, the file search operation has a wide range of applicable scenarios and will not affect the applicability of the automatically generated build file of this disclosure.

[0145] S102. Based on the above compilation dependency information and the filenames and storage paths of each second source code file, establish a global compilation dependency graph.

[0146] The global compilation dependency graph in this disclosure refers to a graph used to describe the compilation order of each second source code file. The global compilation dependency graph includes multiple nodes and multiple directed edges. Each node represents the filename and storage path of a second source code file (the filename and storage path of the second source code file can be used as node identifiers, or node identifiers can be node numbers, etc.). Each directed edge represents the compilation dependency of the node at one end of the edge on the node at the other end of the edge.

[0147] Each compilation dependency in this disclosure can be represented as two nodes and a directed edge. The first source code file in each compilation dependency corresponds to a translated second source code file and its storage path. Therefore, by establishing the correspondence between the nodes represented by the compilation dependency information and the translated second source code file and its storage path (e.g., replacing the nodes represented by the compilation dependency information with the translated second source code file and its storage path), nodes and directed edges based on the second source code file can be obtained. After converting all compilation dependency information into nodes and directed edges based on the second source code file, a global compilation dependency graph can be formed by merging identical nodes.

[0148] In one example, main.sim is set as the main program source code file of the simulation modeling language, agent.sim is the global declaration file of the simulation modeling language, the main program source code file of the general programming language corresponding to main.sim is main.cpp, and the header file of the general programming language corresponding to agent.sim is agent.h. Since there is a compilation dependency between main.sim and agent.sim, that is, the compilation dependency of main.sim on agent.sim, this disclosure can obtain the compilation dependency information of main.cpp on agent.h. That is, main.cpp and its storage path correspond to one node (such as node A), agent.h and its storage path correspond to another node (such as node B), and there is a directed edge between node A and node B, which indicates that node A is a compilation dependency of node B.

[0149] In one example, this disclosure may employ an adjacency list-based graph construction technique to establish a global compiler dependency graph. For instance, all compiler dependency information is traversed, and for each traversed dependency, a corresponding record is added to the adjacency list (e.g., adding an outgoing edge from node A to node B). The in-degree and / or outgoing degree of each node are maintained. After the traversal is complete, the resulting adjacency list is the global compiler dependency graph. This disclosure does not limit the specific implementation method for constructing the global compiler dependency graph.

[0150] S103. Based on the correspondence between the source code files of third-party libraries based on general programming languages ​​and the source code files of libraries based on simulation modeling languages, determine the nodes in the global compilation dependency graph that need to be replaced, and update the corresponding nodes in the global compilation dependency graph using the source code files of third-party libraries and their storage paths.

[0151] The third-party library source code files in this disclosure refer to library function files written in a general-purpose programming language (such as third-party library source code files with the .h extension and third-party library source code files with the .cpp extension). That is, the third-party library source code files are not translated from the first source code file based on the simulation modeling language, but are written in a general-purpose programming language from the initial stage of file formation. Third-party library source code files are typically external dependency library files called by the second source code file, and they are generally not called by the first source code file. It should also be noted that the third-party library source code files in this disclosure can be used to improve the performance of the translated simulation system; this disclosure does not limit the role of the third-party library source code files.

[0152] In one example, the third-party library source code files in this disclosure can be native library source code files provided by the general-purpose programming language itself, or custom library source code files written by the user using the general-purpose programming language. For example, to improve the performance of the simulation engine, the user writes one or more functions with high-performance algorithms (such as functions for algorithm acceleration) in C++. Such functions can form third-party library source code files, i.e., user-defined library source code files. This disclosure does not limit the specific form of the third-party library source code files.

[0153] In one example, since third-party library source code files are typically not called by the first source code file, they will not appear in the first source code file, and consequently, the translated second source code file will not call them. However, because third-party library source code files are specifically designed—for example, one might be designed for a native library provided by a simulation modeling language, or another might be designed for a user-defined library of the same language—there is a correspondence between the third-party library source code files and the library functions called by the first source code file. This disclosure can utilize this correspondence to determine the nodes that need to be replaced in the currently established global compilation dependency graph, and use the third-party library source code files and their storage paths to replace the nodes in the global compilation dependency graph, thereby forming a new global compilation dependency graph. This disclosure does not limit the specific process of updating the global compilation dependency graph.

[0154] This disclosure automatically updates nodes in the global compilation dependency graph by utilizing third-party library source code files and their storage paths. This avoids the need for manual settings in the build file for third-party library source code files, which helps the translated simulation system based on a general programming language to be compatible with various external dependency scenarios such as native libraries and custom libraries. This improves the versatility and scalability of the technical solution disclosed in this disclosure, and also enhances the simulation performance of the translated simulation system.

[0155] In one example, after successfully establishing a global compiler dependency graph, this disclosure can perform graph structure detection processing on the global compiler dependency graph (i.e., detect whether there are structural anomalies in the global compiler dependency graph). Then, the result of the graph structure detection processing is evaluated to determine whether the global compiler dependency graph contains cyclic structures. If it does contain cyclic structures, corresponding measures can be taken for the detected cyclic structures, thereby helping to eliminate compilation problems caused by the cyclic structures. For example, the measures adopted by this disclosure may include: outputting cyclic structure error information, thereby helping users eliminate compilation circular dependencies in simulation modeling language programs.

[0156] In one example, this disclosure can employ a Depth-First Search (DFS) + recursive stack marking technique in the process of detecting cyclic structures in the global compiler dependency graph to quickly locate cyclic structures. For example, this disclosure can locate cyclic structures through the following two steps:

[0157] Step a: Use a graph algorithm (such as the existing Tarjan algorithm) to perform strong connected component detection on the global compiler dependency graph to obtain all strong connected components in the global compiler dependency graph.

[0158] A more specific example is to assume that there are second source code files FILE1, FILE2, FILE3, FILE4, and FILE5, and the dependency information between these second source code files is as follows:

[0159] FILE1: FILE1 → FILE2; (The compilation of the second source code file FILE1 depends on the compilation of the second source code file FILE2)

[0160] FILE2: FILE2 → FILE3; (The compilation of the second source code file FILE2 depends on the compilation of the second source code file FILE3)

[0161] FILE3: FILE3 → FILE2 (The compilation of the second source code file FILE3 depends on the second source code file FILE2)

[0162] FILE4: No dependencies

[0163] FILE5: FILE5 → FILE5 (The compilation of the second source code file FILE5 has a self-dependency).

[0164] The global compilation dependency graph formed using the compilation dependency information of the aforementioned second source code files can be represented in the following form:

[0165] FILE1 → FILE2 → FILE3 → FILE2 (FILE2 and FILE3 form a loop)

[0166] FILE4 is an isolated outer ring node.

[0167] FILE5 → FILE5 (self-loop)

[0168] For the aforementioned global compilation dependency graph, this disclosure utilizes graph algorithms such as Tarjan's algorithm, and the obtained strongly connected components can be represented in the following form:

[0169] {FILE1}, {FILE2,FILE3}, {FILE4}, {FILE5} (marked with self-looping edges)

[0170] Step b: Based on all the obtained strongly connected components, determine the nodes that form a cycle in the global compiler dependency graph.

[0171] A more specific example is that if a strongly connected component includes a node and that node does not have a self-loop edge label, then the node in the strongly connected component is determined not to be a node forming a cycle; if a strongly connected component includes two or more nodes, then the node in the strongly connected component is determined to be a node forming a cycle; if a strongly connected component includes a node and that node has a self-loop edge label, then the node in the strongly connected component is determined to be a node forming a cycle.

[0172] Continuing the previous example, since the number of nodes in {FILE2,FILE3} of the strongly connected components is greater than 1, and {FILE5} has a self-loop edge label, the global compile dependency graph contains two cycles. FILE2 and FILE3 are nodes that form one cycle, while FILE5 is a node that forms the other cycle.

[0173] This disclosure utilizes graph algorithms to obtain all strongly connected components, including self-loops, in a global compilation dependency graph with a single traversal. Since strongly connected components can be considered as the largest strongly connected subgraphs in the global compilation dependency graph, by analyzing the number of nodes and self-loop edges in each of the obtained strongly connected components, it is possible to not only conveniently determine the number of cycles in the global compilation dependency graph and accurately locate the cycle structures in the global compilation dependency graph (such as the nodes that form the cycle and how the nodes form the cycle), but also achieve a linear time complexity. Thus, it helps to improve the efficiency of graph structure detection while ensuring the accuracy of cycle structure detection.

[0174] S104. Generate the build file for the general programming language based on the updated global compilation dependency graph.

[0175] In this disclosure, a build file (such as a makefile) refers to a file that defines the compilation rules, compilation order, and library linking parameters of the source code of a general-purpose programming language. The build file can be used by corresponding tools (such as the make tool) to drive the compilation and linking tools in the general-purpose programming language to automatically complete the project build and form executable code.

[0176] In one example, this disclosure can traverse the global compilation dependency graph, sequentially reading all nodes and directed edges in the graph. During traversal, the principle of traversing dependent nodes first and dependent nodes last should be followed. For example, nodes not depended on by any node are traversed first (i.e., the lowest-level nodes in the global compilation dependency graph, i.e., leaf nodes). Then, nodes dependent on the lowest-level nodes (i.e., the parent nodes of leaf nodes) are traversed, and so on, finally traversing the root node of the global compilation dependency graph. The traversal order of nodes can indicate the compilation order of the source code files represented by the nodes. This compilation order should be reflected in the build file, i.e., statements related to the compilation order are set in the build file based on the traversal order. Furthermore, this disclosure can use topological sorting techniques to determine the traversal order of nodes in the global compilation dependency graph.

[0177] In one example, three source code files are defined: main.cpp, agent.cpp, and utils.cpp. The dependencies between these files are as follows: main.cpp depends on agent.cpp, agent.cpp depends on utils.cpp, and utils.cpp has no dependencies. The global compilation dependency graph for these three files consists of three nodes: node 1 for main.cpp, node 2 for agent.cpp, and node 3 for utils.cpp. Node 1 is the root node, node 2 is a child node of the root node, and node 3 is a child node of node 2. The traversal order (i.e., compilation order) determined using topological sorting is: node 3 -> node 2 -> node 1. This disclosure allows setting corresponding statements in the build file based on this compilation order, such as:

[0178] # Compile all target files

[0179] all: main

[0180] # Final link (executed last)

[0181] main: main.o agent.o utils.o

[0182] $(CXX) -o main main.o agent.o utils.o

[0183] # Compilation order: utils → agent → main

[0184] utils.o: utils.cpp

[0185] $(CXX) -c utils.cpp

[0186] agent.o: agent.cpp

[0187] $(CXX) -c agent.cpp

[0188] main.o: main.cpp

[0189] $(CXX) -c main.cpp

[0190] In one example, this disclosure also requires automatically setting information such as the relative storage path of the target file during the compilation process, the relative storage path of the compiled executable file, compilation option configuration information, incremental compilation information, and cleanup rule information in the build file.

[0191] The relative storage path of the target file in the compilation process refers to the relative path of the intermediate target file (.o / .obj) generated by compiling the source code file (.cpp) in the project directory structure. It is used to specify the generation location of the target file to avoid the phenomenon of target files and source code files being mixed in the same directory. The relative storage path of the target file can be achieved by setting the value of the variable.

[0192] The relative storage path of the compiled executable file refers to the relative path of the final executable file (such as .exe or binary file without extension) generated by linking all object files in the project directory structure. It is used to specify the output location of the final program, which can avoid the phenomenon that the executable file is scattered in the root directory of the project directory structure and make it easier for users to find and run the final generated executable file. The relative storage path of the executable file can also be achieved by setting the value of a variable.

[0193] The compilation option configuration information refers to the set of parameters passed to the compiler (such as g++ or clang) when compiling source code files. This set of parameters may include: language standard, optimization level, warning level, and header file search path, etc., which are used to control compilation behavior and compilation results.

[0194] The incremental compilation information is data used by the build tool to implement incremental compilation. This information can include: the dependency relationship between source files and target files, file modification timestamps, and compilation cache status. The incremental compilation information is used to instruct that only modified source code files and their related dependent files be recompiled, so as to avoid recompiling all source code files every time a build is performed, thereby improving build efficiency.

[0195] The cleanup rules refer to the rules used to delete intermediate object files (.o / .obj), executable files, and temporary files generated during the compilation process. In other words, they are used to clean up build artifacts with one click, providing a clean environment for rebuilding.

[0196] In one example, this disclosure can set a corresponding rule template for the above information, and then replace the placeholders in the rule template with the actual situation information of the project (i.e., the simulation system), ultimately successfully forming the above information in the build file. For example, the rule template set for the above information can be in the following form:

[0197] # Compiler Configuration

[0198] CXX ?= g++

[0199] CXXFLAGS ?= {{COMPILE_OPTIONS}}

[0200] TARGET := {{EXECUTABLE_PATH}}

[0201] OBJ_DIR := {{OBJ_DIR}}

[0202] OBJS := {{ALL_OBJ_FILES}}

[0203] all: $(TARGET)

[0204] $(TARGET): $(OBJS)

[0205] $(CXX) -o $@ $(OBJS)

[0206] %.o: %.cpp

[0207] $(CXX) $(CXXFLAGS) -c $< -o $(OBJ_DIR) / $(basename $@).o

[0208] clean:

[0209] rm -f $(OBJ_DIR) / *.o $(TARGET)

[0210] Here, TARGET is a variable used to set the relative storage path of the executable file; OBJ_DIR is a variable used to set the relative storage path of the object files; {{COMPILE_OPTIONS}} (i.e., compilation options used to determine compiler behavior), {{EXECUTABLE_PATH}} (i.e., the storage path of the executable file, the final output location of the program), {{ALL_OBJ_FILES}} (i.e., a list of all object files, including intermediate files generated during compilation), and {{OBJ_DIR}} (i.e., the object file storage path, the directory used to uniformly manage intermediate files) are all placeholders that need to be replaced.

[0211] This disclosure facilitates the automatic generation of complete build files by automatically setting the relative storage paths of target files, executable files, compilation option configuration information, incremental compilation information, and cleanup rule information in the build file, thereby reducing the generation and maintenance costs of build files. By using variables to configure the relative storage paths of target files and executable files, the risk of path errors caused by hard-coding paths can be avoided. Moreover, when path updates are needed, they can be completed simply by modifying the values ​​of variables, which is conducive to unified management and centralized maintenance of storage paths. This, in turn, improves the robustness of automatically generated build files.

[0212] In one example, this disclosure can also parse a library dependency configuration file based on a simulation modeling language and obtain library linking parameters based on a general-purpose programming language based on the parsing results. This disclosure allows setting linking commands based on these library linking parameters in the build file. The library dependency configuration file in this disclosure refers to a configuration file used to record information such as the names of external libraries required by the project (i.e., the simulation system) and the library file search paths. The library dependency configuration file can be a text file or a JSON / XML file. The library linking parameters based on a general-purpose programming language in this disclosure refer to parameters that the linker can recognize. By parsing the library dependency configuration file, this disclosure can obtain library linking parameters such as the names of dependent external libraries and the library file search paths. These library linking parameters are then used to form complete linking commands in a predetermined format. For example, the external library name is converted to the -l parameter recognized by the linker, and the library file search path is converted to the -L parameter recognized by the linker. The combination of the -l and -L parameters forms a complete linking command. A specific example of a linking command is as follows:

[0213] g++ -o executable_object_file_list -L library_file_search_path -l library_name

[0214] By parsing the library dependency configuration file during the automatic build file generation process, information on all library files that the project depends on can be obtained. This allows for the automatic configuration of external library links by generating corresponding linking commands. It also helps ensure that the linking commands are consistent with the actual project dependencies, avoiding human errors that may occur when users manually set linking commands. This improves the automation level of build file generation and helps ensure the integrity and accuracy of the generated build files.

[0215] The following is a specific example illustrating the process of automatically generating a Makefile in this publication:

[0216] The user is configured to input a set of SimScript source code files (such as main.sim, agent.sim, and event.sim) and a library dependency configuration file translate.conf. After C++ translation, main.sim, agent.sim, and event.sim are transformed into four source code files: main.cpp, agent.cpp, event.cpp, and common.h. By analyzing main.sim, agent.sim, and event.sim statement by statement, this disclosure reveals that main.sim calls functions in agent.sim, and event.sim contains the translated common.h, thus forming a global compilation dependency graph. Library linking parameters can be obtained by parsing the translate.conf configuration file. The Makefile formed using the compilation dependency graph and library linking parameters can take the following form:

[0217] # Automatically generated Makefile

[0218] CC = g++

[0219] CFLAGS = -std=c++17 -O2 -Wall -I. / include

[0220] LDFLAGS = -Llib -lsimlibcpp

[0221] SRCDIR = . / src

[0222] BUILDDIR = . / build

[0223] TARGET = simapp

[0224] SRCS = $(wildcard $(SRCDIR) / *.cpp)

[0225] OBJS = $(SRCS:$(SRCDIR) / %.cpp=$(BUILDDIR) / %.o)

[0226] $(TARGET): $(OBJS)

[0227] $(CC) $(LDFLAGS) -o $@ $^

[0228] $(BUILDDIR) / %.o: $(SRCDIR) / %.cpp $(SRCDIR) / %.h

[0229] $(CC) $(CFLAGS) -c $< -o $@

[0230] clean:

[0231] rm -f $(BUILDDIR) / *.o $(TARGET)

[0232] .PHONY: clean

[0233] Exemplary device

[0234] The structure of one embodiment of the automatic build file generation device based on the compilation process of simulation modeling language disclosed herein is as follows: Figure 2 As shown. The apparatus of this embodiment can be used to implement the corresponding method embodiments of this disclosure. Figure 2 The apparatus shown includes: a module 200 for determining compilation dependencies, a module 210 for determining translation results, a module 220 for building a dependency graph, a module 230 for updating nodes, and a module 240 for generating build files. Optionally, the apparatus of this disclosure may further include: a module 250 for generating linking commands.

[0235] The compilation dependency determination module 200 is mainly used to parse each of the first source code files based on the simulation modeling language to obtain compilation dependency information between different first source code files. For example, when parsing each of the first source code files based on the simulation modeling language, the compilation dependency determination module 200 obtains file import statements or module import statements in the first source code files and obtains the compilation dependencies between at least two first source code files based on these statements. As another example, when parsing each of the first source code files based on the simulation modeling language, the compilation dependency determination module 200 obtains cross-file function call statements in the first source code files and obtains the compilation dependencies between at least two first source code files based on these cross-file function call statements.

[0236] The translation result determination module 210 is mainly used to determine the filenames and storage paths of the translated second source code files based on the first source code files and the translation file naming rules. For example, the translation result determination module 210 determines the filenames and storage paths of the translated source files and header files based on the first source code files containing public declarations and the translation file naming rules. As another example, the translation result determination module 210 determines the filenames and storage paths of the translated header files based on the global declaration files based on the simulation modeling language and the translation file naming rules. As yet another example, the translation result determination module 210 determines the filenames and storage paths of the translated source files based on the simulation modeling language and the translation file naming rules. As yet another example, the translation result determination module 210 determines the filenames and storage paths of the translated source files based on the simulation modeling language and the translation file naming rules. As yet another example, the translation result determination module 210 determines the filenames and storage paths of the translated source files based on the simulation modeling language and the translation file naming rules.

[0237] In one example, for any first source code file, the translation result determination module 210 can generate a search filename based on the filename of the first source code file and the filename of the second source code file determined according to the translation file naming rules. It then performs a corresponding file search operation based on this search filename. If the file search operation successfully finds the search filename in the storage path of the search file, the translation result determination module 210 allows the translated second source code file based on a general programming language corresponding to the first source code file to participate in the establishment of the global compilation dependency graph. Otherwise, the translation result determination module 210 prohibits the translated second source code file based on a general programming language corresponding to the first source code file from participating in the establishment of the global compilation dependency graph. The file search operation can include local search and / or cross-device search based on device network connections.

[0238] The dependency graph establishment module 220 is mainly used to establish a global compilation dependency graph based on the compilation dependency relationship information obtained by the compilation dependency determination module 200 and the filenames and storage paths of the second source code files obtained by the translation result determination module 210. In the global compilation dependency graph, nodes represent the filenames and storage paths of the second source code files, and directed edges in the global compilation dependency graph represent the compilation dependencies of nodes located at one end of the edge, with the nodes located at the other end of the directed edge being the nodes whose compilation dependencies are located at the other end of the edge.

[0239] The node update module 230 is mainly used to determine the nodes that need to be replaced in the global compilation dependency graph established by the dependency graph building module 220, based on the correspondence between the source code files of third-party libraries based on general programming languages ​​and the source code files of libraries based on simulation modeling languages. It then updates the corresponding nodes in the global compilation dependency graph using the third-party library source code files and their storage paths. For example, the node update module 230 can determine the nodes that need to be replaced in the global compilation dependency graph based on the correspondence between the source code files of third-party libraries based on general programming languages ​​and the source code files of native libraries based on simulation modeling languages. As another example, the node update module 230 can determine the nodes that need to be replaced in the global compilation dependency graph based on the correspondence between the source code files of third-party libraries based on general programming languages ​​and the source code files of custom libraries based on simulation modeling languages.

[0240] The build file generation module 240 is mainly used to generate build files for a general programming language based on the updated global compilation dependency graph of the node update module 230.

[0241] In one example, the build file generation module 240 can also set the relative storage path of the target files during the compilation process, the relative storage path of the compiled executable file, compilation option configuration information, incremental compilation information, and cleanup rule information in the build file. The relative storage paths of the target files and executable files can be set by setting the values ​​of variables.

[0242] The linking command generation module 250 is mainly used to parse the library dependency configuration file based on the simulation modeling language, thereby obtaining the library linking parameters based on the general programming language, and setting the linking command based on the library linking parameters in the above-mentioned construction file.

[0243] The specific operations performed by the module for determining compilation dependencies 200, the module for determining translation results 210, the module for establishing dependency graphs 220, the module for updating nodes 230, the module for generating build files 240, and the module for generating linking commands 250 in this disclosure can be found in the descriptions in the above method embodiments, and will not be described in detail here.

[0244] Exemplary electronic devices

[0245] The following is for reference. Figure 3 To describe an electronic device according to embodiments of the present disclosure. Figure 3 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. (As follows) Figure 3 As shown, the electronic device 31 includes one or more processors 311 and memory 312.

[0246] The processor 311 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 31 to perform desired functions.

[0247] The memory 312 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, and flash memory. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 311 may execute the program instructions to implement the automatic build file generation method based on the simulation modeling language compilation process described above in the various embodiments of this disclosure, and / or other desired functions.

[0248] In one example, electronic device 31 may further include input device 313 and output device 314, etc., these components being interconnected via a bus system and / or other forms of connection mechanism (not shown). Furthermore, the input device 313 may include, for example, a keyboard, mouse, etc. The output device 314 can output various information to the outside. The output device 314 may include, for example, a display, speaker, printer, and communication network and its connected remote output devices, etc.

[0249] Of course, for the sake of simplicity, Figure 3 Only some of the components of the electronic device 31 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 31 may include any other suitable components depending on the specific application.

[0250] Exemplary computer program products and computer-readable storage media

[0251] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the automatic generation method of build files in the simulation modeling language compilation process according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0252] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0253] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the automatic generation method of build files in the simulation modeling language compilation process according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0254] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (not an exhaustive list) may include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0255] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0256] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0257] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0258] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0259] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0260] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0261] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for automatically generating build files during the compilation process of a simulation modeling language, characterized in that, The method includes: Each first source code file based on the simulation modeling language is parsed to obtain the compilation dependency information between different first source code files; Based on the filenames of the first source code files and the naming rules for the translated files, determine the filenames and storage paths of the translated second source code files based on the general programming language; Based on the compilation dependency information and the filenames and storage paths of the second source code files, a global compilation dependency graph is established; wherein, the nodes in the global compilation dependency graph represent the filenames and storage paths of the second source code files, and the directed edges in the global compilation dependency graph represent the compilation dependencies of the node at the starting end of the edge and the node at the pointing end of the edge. Based on the correspondence between the source code files of third-party libraries based on general programming languages ​​and the source code files of libraries based on simulation modeling languages, the nodes that need to be replaced in the global compilation dependency graph are determined, and the corresponding nodes in the global compilation dependency graph are updated using the source code files of the third-party libraries and their storage paths. Based on the updated global compilation dependency graph, a build file for a general programming language is generated.

2. The method according to claim 1, characterized in that, The step of parsing each first source code file based on the simulation modeling language to obtain compilation dependency information between different first source code files includes: Each of the first source code files based on the simulation modeling language is parsed. When the file import statements or module import statements in the first source code files are obtained, the compilation dependency relationship between at least two first source code files is obtained based on the file import statements or module import statements.

3. The method according to claim 1, characterized in that, The step of parsing each of the first source code files based on the simulation modeling language to obtain the compilation dependency information between the first source code files based on the simulation modeling language includes: Each of the first source code files based on the simulation modeling language is parsed. When the cross-file function call statements in the first source code files are obtained, the compilation dependency relationship between at least two first source code files is obtained based on the cross-file function call statements.

4. The method according to claim 1, characterized in that, The step of determining the filenames and storage paths of the translated second source code files based on the general programming language according to the filenames of the first source code files and the naming rules for translated files includes at least one of the following: Based on the first source code file containing public declarations and the naming rules for the transpiled files, determine the filenames and storage paths of the transpiled source and header files based on the general programming language; Based on the global declaration file and the naming rules of the translation file based on the simulation modeling language, determine the filename and storage path of the translated header file based on the general programming language; Based on the naming rules of the implementation files and their translation files based on the simulation modeling language, determine the filename and storage path of the translated source files based on the general programming language; Based on the naming rules of the main program file and its translated files based on the simulation modeling language, determine the filename and storage path of the translated source file based on the general programming language.

5. The method according to claim 1, characterized in that, The step of determining the filenames and storage paths of the translated second source code files based on the general programming language according to the filenames of the first source code files and the naming rules for translated files further includes: For any first source code file, the filename to be searched is formed based on the filename of the second source code file determined by the filename of the first source code file and the naming rules of the transpiled file. A file search operation is performed based on the filename to be searched. If the file search operation results in the filename to be searched being successfully found in the storage path of the file to be searched, the translated second source code file based on the general programming language corresponding to the first source code file is allowed to participate in the establishment of the global compilation dependency graph. Otherwise, the translated second source code file based on the general programming language corresponding to the first source code file is prohibited from participating in the establishment of the global compilation dependency graph. The file search operation includes: local search and / or cross-device search based on device network connection.

6. The method according to claim 1, characterized in that, The step of determining the nodes that need to be replaced in the global compilation dependency graph based on the correspondence between third-party library source code files based on general-purpose programming languages ​​and library source code files based on simulation modeling languages ​​includes: Based on the correspondence between third-party library source code files based on general-purpose programming languages ​​and native library source code files based on simulation modeling languages, determine the nodes in the global compilation dependency graph that need to be replaced; and / or Based on the correspondence between the source code files of third-party libraries based on general programming languages ​​and the source code files of custom libraries based on simulation modeling languages, the nodes that need to be replaced in the global compilation dependency graph are determined.

7. The method according to claim 1, characterized in that, The method further includes: Set the relative storage path of the target files during the compilation process in the build file; Set the relative storage path of the compiled executable file in the build file; Configure compilation options in the build file; Set incremental compilation information in the build file; Set the cleanup rule information in the build file; The relative storage paths of the target file and the executable file are both determined by setting the values ​​of variables.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: The library dependency configuration file based on the simulation modeling language is parsed to obtain the library linking parameters based on the general programming language, and the linking command based on the library linking parameters is set in the build file.

9. An automatic build file generation device based on the compilation process of a simulation modeling language, characterized in that, The device includes: The compilation dependency module is determined to parse each first source code file based on the simulation modeling language and obtain the compilation dependency information between different first source code files. The translation result determination module is used to determine the filename and storage path of each translated second source code file based on the filename of each first source code file and the translation file naming rules. A dependency graph building module is used to build a global compilation dependency graph based on the compilation dependency information and the filenames and storage paths of each second source code file; wherein, the nodes in the global compilation dependency graph represent the filenames and storage paths of the second source code files, and the directed edges in the global compilation dependency graph represent the compilation dependencies of the node at the starting end of the edge and the node at the pointing end of the edge. The node update module is used to determine the nodes that need to be replaced in the global compilation dependency graph based on the correspondence between the source code files of third-party libraries based on general programming languages ​​and the source code files of libraries based on simulation modeling languages, and to update the corresponding nodes in the global compilation dependency graph using the source code files of third-party libraries and their storage paths. The build file generation module is used to generate build files for a general programming language based on the updated global compilation dependency graph.

10. A computer-readable storage medium storing a computer program for performing the method of any one of claims 1-8.

11. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method of any one of claims 1-8.

Images