Compiling language-oriented code conversion method and related equipment

Abstract

The invention provides a compiling language-oriented code conversion method and related equipment. The method comprises the steps of obtaining a first code based on a first platform; converting a first platform element associated with the first platform in the first code based on a preset mapping rule base to obtain a second code based on a second platform; performing dependency library identification on the second code to obtain a corresponding dependency library database; automatically installing a dependency library corresponding to the second platform based on the dependency library database, and generating a script construction instruction; generating a configuration file corresponding to the second platform and a corresponding compiling option based on the script construction instruction and the dependency library; and generating a code conversion result based on the second code, the configuration file and the compiling option.

Description

Technical Field

[0001] This disclosure relates to the field of code conversion, and more particularly to a code conversion method and related equipment for compiled languages. Background Technology

[0002] With the widespread adoption of multiple operating systems (such as Windows, Linux, and macOS), the demand for cross-platform software development has surged. In cross-platform software development, due to differences in operating system interfaces, compiler characteristics, and dependency library paths / naming rules, developers need to manually adapt code and dependency libraries for different platforms, resulting in long development cycles and high maintenance costs. Existing cross-platform tools (such as Qt and CMake) have the following problems: low code migration efficiency, requiring developers to manually write platform adaptation code, which is inefficient and prone to introducing compatibility errors; complex dependency management, requiring manual intervention for dependency library installation paths and version compatibility, resulting in high cross-platform compilation failure rates and inability to recognize dynamically loaded libraries or implicit symbol references; redundant conditional compilation, with numerous #ifdef branches leading to bloated code, poor readability, and high maintenance costs; and incomplete build script generation, lacking the ability to automatically integrate dependency library paths and compilation options. Summary of the Invention

[0003] This disclosure proposes a code conversion method and related equipment for compiled languages, which can at least partially solve the above-mentioned technical problems.

[0004] The first aspect of this disclosure provides a code transformation method for compiled languages, including: Obtain the first code based on the first platform; Based on a preset mapping rule base, the first platform elements associated with the first platform in the first code are transformed to obtain the second code based on the second platform; The second code is subjected to dependency library identification to obtain the corresponding dependency library database; The dependency libraries corresponding to the second platform are automatically installed based on the dependency library database, and build script instructions are generated. Based on the build script instructions and the dependency libraries, generate the configuration file and corresponding compilation options for the second platform; The code conversion result is generated based on the second code, the configuration file, and the compilation options.

[0005] A second aspect of this disclosure provides a code conversion apparatus for compiled languages, comprising: The acquisition module is used to acquire the first code based on the first platform. A cross-platform code conversion engine is used to convert the first platform elements associated with the first platform in the first code based on a preset mapping rule library to obtain second code based on the second platform; The dependency library auto-identification component is used to identify the dependency libraries in the second code to obtain the corresponding dependency library database; and to automatically install the dependency libraries corresponding to the second platform based on the dependency library database, and generate build script instructions; A smart build configuration generator is used to generate a configuration file and corresponding compilation options for the second platform based on the build script instructions and the dependency libraries. The output module is used to generate code conversion results based on the second code, the configuration file, and the compilation options.

[0006] A third aspect of this disclosure provides an electronic device including one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and executed by the one or more processors, the programs including instructions for performing the method according to the first aspect.

[0007] A fourth aspect of this disclosure provides a non-volatile computer-readable storage medium containing a computer program that, when executed by one or more processors, causes the processors to perform the method described in the first aspect.

[0008] A fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect.

[0009] As described above, the code conversion method and related equipment for compiled languages ​​provided in this disclosure acquire the original code based on a first platform, accurately identify and convert platform-specific elements such as syntax and system calls related to the first platform using a preset mapping rule library, and generate equivalent code that can run on a second platform. Subsequently, the converted code undergoes deep dependency library identification, a dependency library database is built, and the corresponding dependency libraries for the second platform are automatically installed, while simultaneously generating adapted build script instructions. Based on the build instructions and dependency library information, configuration files (such as CMakeLists.txt, Makefile, etc.) and compilation options (such as optimization parameters, architecture identifiers, etc.) for the second platform are dynamically generated. Finally, the converted code, configuration files, and compilation options are integrated to output a complete code package that can be directly compiled and run on the second platform. This significantly reduces cross-platform portability costs, eliminates manual adaptation errors, and ensures that the code maintains functional consistency and compilation reliability across different platforms. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in this disclosure or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of a code conversion architecture for compiled languages ​​according to an embodiment of this disclosure.

[0012] Figure 2 This is a schematic diagram of the hardware structure of an exemplary electronic device according to an embodiment of the present disclosure.

[0013] Figure 3 This is a flowchart illustrating the code conversion method for compiled languages ​​according to an embodiment of this disclosure.

[0014] Figure 4 This is a schematic diagram illustrating the principle of code conversion in an embodiment of this disclosure.

[0015] Figure 5 This is a schematic diagram illustrating the principle of dependency library identification in an embodiment of this disclosure.

[0016] Figure 6 This is a schematic diagram of a code conversion apparatus for compiled languages ​​according to an embodiment of the present disclosure. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0018] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0019] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0020] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0021] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0022] Figure 1 A schematic diagram of a code transformation architecture for compiled languages, according to an embodiment of this disclosure, is shown. (Reference) Figure 1 The code translation architecture 100 for compiled languages ​​may include a server 110, a terminal 120, and a network 130 providing a communication link. The server 110 and the terminal 120 can be connected via a wired or wireless network 130. The server 110 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, security services, and CDN.

[0023] Terminal 120 can be implemented in hardware or software. For example, when terminal 120 is implemented in hardware, it can be various electronic devices with a display screen and support page display, including but not limited to smartphones, tablets, e-book readers, laptops, and desktop computers. When terminal 120 is implemented in software, it can be installed in the electronic devices listed above; it can be implemented as multiple software programs or software modules (e.g., software programs or software modules used to provide distributed services) or as a single software program or software module, without specific limitations.

[0024] It should be noted that the code conversion method for compiled languages ​​provided in this application embodiment can be executed by the terminal 120 or by the server 110. It should be understood that... Figure 1 The number of terminals, networks, and servers shown is for illustrative purposes only and is not intended to be a limitation. Any number of terminals, networks, and servers can be used depending on implementation needs.

[0025] Figure 2 A schematic diagram of the hardware structure of an exemplary electronic device 200 provided in an embodiment of this disclosure is shown. For example... Figure 2 As shown, the electronic device 200 may include: a processor 202, a memory 204, a network module 206, a peripheral interface 208, and a bus 210. The processor 202, memory 204, network module 206, and peripheral interface 208 are interconnected within the electronic device 200 via the bus 210.

[0026] Processor 202 may be a Central Processing Unit (CPU), a Neural Processing Unit (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits. Processor 202 can be used to perform functions related to the techniques described in this disclosure. In some embodiments, processor 202 may also include multiple processors integrated as a single logic component. For example, such as... Figure 2 As shown, processor 202 may include multiple processors 202a, 202b and 202c.

[0027] Memory 204 can be configured to store data (e.g., instructions, computer code, etc.). Figure 2 As shown, the data stored in memory 204 may include program instructions (e.g., program instructions for implementing the code conversion method for compiled languages ​​according to embodiments of this disclosure) and data to be processed (e.g., the memory may store configuration files of other modules, etc.). Processor 202 may also access the program instructions and data stored in memory 204 and execute the program instructions to operate on the data to be processed. Memory 204 may include volatile or non-volatile storage devices. In some embodiments, memory 204 may include random access memory (RAM), read-only memory (ROM), optical disk, magnetic disk, hard disk, solid-state drive (SSD), flash memory, memory stick, etc.

[0028] Network module 206 can be configured to provide communication with other external devices to electronic device 200 via a network. This network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, Near Field Communication (NFC), etc.), a cellular network, the Internet, or a combination thereof. It is understood that the type of network is not limited to the specific examples described above. In some embodiments, network module 206 may include any combination of any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc.

[0029] The peripheral interface 208 can be configured to connect the electronic device 200 to one or more peripheral devices to enable information input and output. For example, peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, and various sensors, as well as output devices such as displays, speakers, vibrators, and indicator lights.

[0030] Bus 210 can be configured to transmit information between various components of electronic device 200 (e.g., processor 202, memory 204, network module 206, and peripheral interface 208), such as internal buses (e.g., processor-memory bus), external buses (USB port, PCI-E bus), etc.

[0031] It should be noted that although the architecture of the above-described electronic device 200 only shows the processor 202, memory 204, network module 206, peripheral interface 208, and bus 210, in specific implementations, the architecture of the electronic device 200 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the architecture of the above-described electronic device 200 may only include the components necessary for implementing the embodiments of this disclosure, and does not necessarily include all the components shown in the figures.

[0032] With the widespread adoption of multiple operating systems (such as Windows, Linux, and macOS), the demand for cross-platform software development has surged. In cross-platform software development, due to differences in operating system interfaces, inconsistent compiler features, and different dependency library paths / naming rules, developers need to manually adapt code and dependency libraries for different platforms, resulting in long development cycles and high maintenance costs. While existing cross-platform tools (such as Qt and CMake) can partially solve compilation compatibility issues, they cannot automatically handle platform-related code differences, such as API calls and system-level dependency library bindings. Qt is a cross-platform C++ framework used for developing graphical user interfaces and applications. It supports modular design and covers GUI, networking, databases, multithreading, and other functionalities. Its core features include the signal and slot mechanism and cross-platform compatibility (Windows, Linux, macOS, etc.). CMake is a cross-platform build tool used for automated compilation configuration.

[0033] However, while the Qt framework can provide a cross-platform API abstraction layer, it requires binding to specific framework APIs and cannot adapt to system-level components or legacy code. Clang-Tidy (the official LLVM tool) provides code refactoring capabilities, but only supports simple syntax refactoring, lacks operating system API mapping capabilities, and cannot automate cross-platform interface replacement. vcpkg (Microsoft's open-source package manager) supports cross-platform dependency installation, but requires manually writing dependency declaration files and cannot dynamically identify implicit dependencies in the code (such as dynamically loaded libraries). These technologies all suffer from the following technical problems: Low code migration efficiency: Developers need to manually write platform adaptation code, which is inefficient and prone to introducing compatibility errors.

[0034] Dependency management is complex: the installation path and version compatibility of dependency libraries require manual intervention, cross-platform compilation has a high failure rate, and it cannot recognize dynamically loaded libraries or implicit symbol references.

[0035] Redundant conditional compilation: A large number of #ifdef branches lead to bloated code, poor readability, and high maintenance costs.

[0036] The build script is incomplete: it lacks the ability to automatically integrate dependency library paths and compilation options.

[0037] In view of this, the present disclosure provides a code conversion method and related equipment for compiled languages. This method acquires the original code based on a first platform, accurately identifies and converts platform-specific elements such as syntax and system calls related to the first platform using a preset mapping rule library, generating equivalent code that can run on a second platform. Subsequently, it performs deep dependency library identification on the converted code, constructs a dependency library database, and automatically installs the corresponding dependency libraries for the second platform, while simultaneously generating adapted build script instructions. Based on the build instructions and dependency library information, it dynamically generates configuration files (such as CMakeLists.txt, Makefile, etc.) and compilation options (such as optimization parameters, architecture identifiers, etc.) for the second platform. Finally, it integrates the converted code, configuration files, and compilation options to output a complete code package that can be directly compiled and run on the second platform. This significantly reduces cross-platform portability costs, eliminates manual adaptation errors, and ensures functional consistency and compilation reliability of the code across different platforms.

[0038] See Figure 3 , Figure 3 A schematic flowchart illustrating a code conversion method for compiled languages ​​according to an embodiment of the present disclosure is shown. The code conversion method for compiled languages ​​according to an embodiment of the present disclosure can be deployed on a terminal or server. Figure 3 In the code conversion method 300 for compiled languages, the following steps may be further included.

[0039] In step S310, the first code based on the first platform is obtained.

[0040] The first platform can refer to the original operating environment, such as Windows, Linux, or macOS. The first code can be the original code within that environment. Obtaining the first code based on the first platform can be achieved through automated tools (such as pulling code repositories with Git and verifying integrity using Shell / Python scripts) to accurately extract source code, header files, and build configurations. Metadata such as the operating system, compiler version, and hardware architecture of the first platform is recorded simultaneously (e.g., generating a `platform_metadata.json` file). Furthermore, static analysis or build logs are used to identify dependency library versions and paths, ensuring that the code is complete and dependencies are clearly defined. Standardized processes and metadata recording provide reliable input for subsequent rule mapping, dependency resolution, and compilation option generation, effectively reducing the portability risks caused by environmental differences and improving the efficiency and accuracy of cross-platform development.

[0041] In step S320, the first platform element associated with the first platform in the first code is transformed based on a preset mapping rule base to obtain the second code based on the second platform.

[0042] Specifically, by using a pre-defined mapping rule library (which stores mapping rules for differences in syntax, library functions, compilation instructions, etc. between platforms), elements of the first platform (such as API calls, compiler macros, and file paths) that are strongly bound to the first platform (such as Linux) in the first code (the code of the original platform) are automatically converted and replaced with equivalent code of the second platform (such as Windows) (such as LoadLibrary, _beginthreadex). This ultimately generates second code that can be compiled and run on the second platform. This effectively solves the problems of syntax incompatibility and functional differences in cross-platform development, significantly reduces manual porting costs, and improves code portability.

[0043] In some embodiments, the first platform element associated with the first platform in the first code is transformed based on a preset mapping rule base to obtain second code based on the second platform, including: The first code is parsed to obtain an abstract syntax tree; The first platform element is extracted from the first code based on the abstract syntax tree; the first platform element includes API calls, compiler macros, and file paths. The mapping rules in the preset mapping rule library are matched with the first platform element, and the second code is obtained based on the matching result.

[0044] The process involves parsing the first code to generate an Abstract Syntax Tree (AST), extracting platform-specific elements (including API calls like dlopen, compiler macros like __attribute__, and file paths) from the first platform. These extracted elements are then matched against rules in a pre-defined mapping rule base (e.g., mapping Linux's fork() to Windows' CreateProcess), ultimately generating second code adapted for the second platform (e.g., Windows / MSVC). This automated rule matching eliminates platform differences, ensuring correct compilation and execution on the target platform, significantly reducing manual porting costs and improving cross-platform development efficiency.

[0045] In some embodiments, the mapping rules in a preset mapping rule base are matched with the first platform element, and the second code is obtained based on the matching result, including: In response to the first platform element matching the mapping rule, the first platform element in the first code is transformed based on the mapping rule to obtain a code branch based on the second platform; and the code branch is conditionally compiled and merged to obtain a platform abstraction layer. In response to the mismatch between the first platform element and the interface mapping rule, the first platform element in the first code is manually converted to obtain manually converted code; The second code is obtained based on the platform abstraction layer and the manually converted code.

[0046] The process involves automatically matching extracted first-platform elements with rules in a pre-defined mapping rule base. If a match is found, the platform-specific elements in the original code are converted into equivalent code branches for the second platform, and conditional compilation (e.g., `#ifdef _WIN32`) is used to merge these branches into a Platform Abstraction Layer (PAL), achieving cross-platform compatibility. If an element does not match a rule, manual intervention completes the conversion, generating manually converted code. Finally, the Platform Abstraction Layer and the manually converted code are integrated to generate second code that can be compiled and run on the second platform. This approach balances automation efficiency with manual flexibility, reducing repetitive work while ensuring accurate handling of complex platform differences, significantly improving the success rate and maintainability of cross-platform code porting.

[0047] Specifically, see Figure 4 , Figure 4 A schematic diagram illustrating the principle of code conversion according to an embodiment of this disclosure is shown. Figure 4 The extracted platform-related elements include operating system API calls (such as fork() / CreateProcess), compiler macros (such as __linux__ / _WIN32), and file path separators (such as / / \). Rule base matching involves matching the code against the API mapping rule base. Code that matches successfully is transformed; unmatched code is marked for further manual processing, and the rule base is updated after manual processing. Conditional compilation merging refers to merging preprocessor directives into a platform abstraction layer (PAL). That is, the extracted elements are automatically matched against the API mapping rule base. If a match is successful, the code is directly transformed according to the rules (such as replacing fork() with CreateProcess). If a match fails, the element is marked and enters the manual processing flow. After the developer completes the transformation, the case is updated to the rule base to enhance subsequent automation capabilities. The transformed code branches are merged into the PAL using conditional compilation directives (such as #ifdef), shielding underlying platform differences and ultimately generating second code that can be compiled and run on a second platform. This approach, by covering common platform differences with automated rules, combined with manual handling of complex scenarios and continuous optimization of the rule base, improves cross-platform development efficiency while ensuring code portability and maintainability.

[0048] In step S330, the second code is subjected to dependency library identification to obtain the corresponding dependency library database.

[0049] Analyzing the second code can identify its direct or indirect dependencies on external libraries (such as dynamic link libraries and static libraries). A dependency library database refers to a structured collection of data storing information about the second code's dependencies, used for subsequent dependency management, build configuration, or deployment. Specifically, code parsing tools (such as Clang's AST analysis) can identify header files included with `#include` or library names called by `dlopen / LoadLibrary`. Alternatively, the code can be compiled and run on the target platform to capture libraries loaded at runtime (e.g., using tools like `ldd` or `Dependency Walker`).

[0050] In some embodiments, the second code is subjected to dependency library identification to obtain a corresponding dependency library database, including: The first dependency library is determined based on the undefined symbols in the code branch; The second code is executed in a sandbox environment to determine the dynamically loaded second dependency library; The dependency library database is determined based on the first dependency library and the second dependency library.

[0051] The process of parsing the code branch of the second code can utilize linker or compiler tools (such as nm and objdump) to detect undefined symbols (such as unresolved function calls) and deduce the first dependent library (such as libraries statically linked at compile time). Alternatively, the second code can be executed in a sandbox environment (such as isolated Docker containers or virtual machines), and runtime tools (such as strace and Process Monitor) can capture dynamically loaded second dependent libraries (such as libraries called by dlopen or LoadLibrary). Finally, static and dynamic dependency information are integrated to generate a dependency library database containing library names, versions, and acquisition methods. Static analysis ensures the completeness of compile-time dependencies, while dynamic analysis covers runtime dynamic loading scenarios, effectively avoiding compilation or runtime errors caused by missing dependencies and significantly improving the deployment reliability and maintainability of cross-platform code.

[0052] In some embodiments, executing the second code in a sandbox environment to determine a dynamically loaded second dependency library includes: In response to determining that the second platform is a Linux system, the LD_DEBUG environment variable is obtained to obtain library loading information, and the second dependent library is determined based on the library loading information; In response to determining that the second platform is a macOS system, the DTrace script monitors dlopen or dlsym calls to identify the second dependent library; In response to determining that the second platform is a Windows system, the LoadLibrary call or GetProcAddress call is intercepted via API hook to identify the second dependency library.

[0053] Specifically, different technical approaches are employed in the sandbox environment to address the varying operating system characteristics of the second platform: For Linux systems, the LD_DEBUG environment variable is set and its output library loading logs are parsed to locate dynamically loaded libraries (such as .so files called by dlopen); for macOS systems, the DTrace script is used to monitor dlopen or dlsym system calls in real time to capture dynamic library loading behavior; for Windows systems, API hooks (such as the Detours library) are used to intercept LoadLibrary or GetProcAddress calls to extract information about dynamically loaded DLLs—ultimately, the capture results from each platform are integrated to generate a complete list of second-platform dependency libraries. This solution, by specifically adapting to the dynamic linking mechanisms of different platforms, ensures that all runtime dependencies are captured without omission, effectively solving compatibility issues caused by missing dynamic libraries in cross-platform deployments, and significantly improving the reliability and maintainability of code deployment.

[0054] Specifically, see Figure 5 , Figure 5 A schematic diagram illustrating the principle of dependency library identification according to an embodiment of this disclosure is shown. Figure 5 In the process, static analysis scans header files for `#include` statements and symbolic references to generate an initial dependency list. Dynamic analysis executes the compiled binary in a sandbox environment, employing different tracing methods depending on the operating system: for Linux systems, library loading information is captured via the `LD_DEBUG` environment variable; for macOS systems, the `DTrace` script monitors `dlopen` and `dlsym` calls; for Windows systems, API hooks intercept `LoadLibrary` and `GetProcAddress` calls. For example, implicit dependency identification can be implemented based on dynamic analysis. (1) Input code void* lib = dlopen("libssl.so", RTLD_LAZY); / / Dynamically load OpenSSL (2) Dependency identification Dynamically analyze dlopen call parameters to identify the dependent library libssl.

[0055] Invoke Conan to install OpenSSL and generate CMake configuration: find_package(OpenSSL REQUIRED) target_link_libraries(... OpenSSL::SSL) As can be seen, by using dynamic analysis techniques (such as parsing the dlopen call parameters in the code) to accurately identify implicit dependency libraries (such as dynamically loaded libssl.so), and combining this with package management tools (such as Conan) to automatically install dependency libraries and generate appropriate CMake configurations (such as find_package(OpenSSL REQUIRED) and target_link_libraries directives), this solution can automatically capture dynamic loading behavior, avoid manually missing dependencies, and ensure that dependency libraries are correctly installed and linked on the target platform. This significantly improves the integrity and compilation reliability of cross-platform code conversion, and is especially suitable for C / C++ projects that require dynamically loaded libraries.

[0056] In some embodiments, method 300 may further include: Construct a dependency graph based on the first dependency library and the second dependency library; In response to the detection of a version conflict dependency in the dependency database, the version conflict dependency is updated to a compatible version dependency.

[0057] This system constructs a dependency graph based on the first dependency library (statically inferred at compile time) and the second dependency library (dynamically captured at runtime). This graph visually represents the dependencies between libraries (e.g., library A depends on library B's v1.0 and library C's v2.0). It then detects version conflicts in the dependency library database (e.g., library B's v1.0 is incompatible with library C's v2.0) through topology analysis or version constraint checks (e.g., semantic versioning rules). If a conflict is detected, the conflicting dependency library is automatically updated to a compatible version based on the dependency graph and compatibility rules (e.g., prioritizing the latest patch version that satisfies all dependencies). This process (e.g., upgrading library B to v1.1 to be compatible with library C's v2.0) ultimately generates a conflict-free dependency library database. By graphing dependencies and automating version coordination, this system effectively avoids compilation errors or runtime crashes caused by dependency version conflicts, significantly improving the deployment efficiency and stability of cross-platform code.

[0058] In step S340, the dependency libraries corresponding to the second platform are automatically installed based on the dependency library database, and build script instructions are generated.

[0059] Based on a pre-built dependency database (including library name, version, platform, and acquisition method), the system can automatically identify the package management tools for the second platform (such as apt / yum for Linux, brew for macOS, vcpkg or Chocolatey for Windows), download and install the corresponding versions of dependency libraries (e.g., automatically executing `apt install libssl-dev=1.1.1`). Simultaneously, it generates adapted build script instructions based on the dependency graph and platform characteristics (such as CMake's `find_package` or Makefile's LDFLAGS configuration), ensuring that code can be compiled and linked on the target platform without manual intervention. This solution, through automated dependency library installation and intelligent generation of build instructions, completely eliminates the burden of manual environment configuration for developers, significantly improving the deployment efficiency and consistency of cross-platform projects.

[0060] In step S350, the configuration file and corresponding compilation options for the second platform are generated based on the build script instructions and the dependency libraries.

[0061] Based on build script instructions (such as CMake's `target_link_libraries` or Makefile's `LDFLAGS`) and a dependency database (containing library paths, versions, and header file locations), the system automatically generates configuration files (such as the `find_package` configuration in `CMakeLists.txt` and the `.pc` file in `pkg-config`) and compilation options (such as `-I / usr / local / include` on Linux and ` / I "C:\deps\include"` on Windows) adapted to the second platform. This ensures that the compiler can correctly find the header files and linked libraries of the dependencies. For example, if the dependency database records the path and version of OpenSSL, the system will generate the `find_package(OpenSSL 1.1.1 REQUIRED)` instruction and add the `-lssl -lcrypto` linking options. By automatically generating configuration files and compilation options, the system completely eliminates the risk of errors from manual configuration, ensuring that cross-platform code can be correctly compiled and linked in different environments, significantly improving development efficiency and deployment reliability.

[0062] For example, taking the migration of code from Windows to Linux using the CMake build tool as an example, the build scripts are compared as follows: Original configuration (Windows): add_executable(app WIN32 main.cpp) target_link_libraries(app ws2_32) Automatic configuration generation (Linux): add_executable(app main.cpp) find_package(Threads REQUIRED) target_link_libraries(app PRIVATE Threads::Threads) target_compile_options(app PRIVATE -pthread) This approach parses build script instructions from the original platform (e.g., `target_link_libraries(app ws2_32)`), identifies its dependent libraries (e.g., the `ws2_32` network library for Windows), and then automatically generates equivalent configuration files and compilation options based on a dependency library database and the characteristics of the second platform (e.g., Linux). For example, it maps Windows' `ws2_32` to Linux's `Threads` library, generating the `find_package(Threads REQUIRED)` instruction and adding the `-pthread` compilation option to ensure multi-threading support; simultaneously, it removes platform-specific markers (e.g., `WIN32`) to generate a concise `add_executable(app main.cpp)`. This solution significantly reduces the configuration complexity of cross-platform development by automatically mapping APIs and compilation options across different platforms, ensuring that code compiles correctly on the target platform without manual intervention. It is particularly suitable for complex projects that require rapid adaptation to multiple platforms.

[0063] As can be seen, by automatically injecting the command (find_package) for finding and configuring dependency libraries and platform-specific compilation options (such as -pthread in Linux to support multithreading) based on the target platform, the manual configuration work of developers in cross-platform projects can be reduced. At the same time, platform-specific flags are hidden, a unified build interface is generated, and a platform abstraction layer is implemented.

[0064] In step S360, a code conversion result is generated based on the second code, the configuration file, and the compilation options.

[0065] This process integrates platform-adapted second-party code (such as code with converted path separators and API calls), configuration files (such as the automatically generated `find_package` directive in `CMakeLists.txt`), and compilation options (such as `-pthread` or ` / I"C:\deps\include"`) to generate a code conversion result that can be directly compiled and run on the second platform. For example, in a Linux environment, the system will convert Windows-specific `ws2_32` dependencies to `Threads::Threads` and generate compilation instructions containing `-pthread`, ultimately outputting a complete executable file or library.

[0066] In some embodiments, method 300 may further include: A Dockerfile is generated based on the configuration file, and a Docker image is generated based on the Dockerfile. Running the Docker image yields the corresponding Docker container; The code transformation result is run in the Docker container to isolate the compilation environment.

[0067] The process involves dynamically generating a Dockerfile based on automatically generated configuration files (such as CMakeLists.txt containing platform-specific dependency directives and compilation options). This Dockerfile defines the operating system, dependency installation commands (such as apt install or vcpkg install), and build toolchain configuration required to build the image. The Docker engine then builds the Docker image, ensuring environment consistency. Running this image generates a Docker container, which executes the transformed code (such as executables or libraries adapted for the target platform). The container's lightweight isolation feature shields the host machine from environmental differences (such as library version conflicts between different Linux distributions). By encapsulating the compilation environment and dependencies into a reusable image using containerization technology, the deployment speed, portability, and team collaboration efficiency of cross-platform projects are significantly improved. This approach is suitable for scenarios requiring parallel development of multiple versions or continuous integration (CI).

[0068] Therefore, the method of this disclosure reduces manual intervention by automatically replacing cross-operating system APIs; dynamically identifies explicit / implicit dependency libraries in the code and automatically adapts to the target platform to avoid compilation or runtime errors caused by missing dependencies; optimizes conditional compilation branches to generate concise and maintainable multi-platform code; and automatically generates cross-platform build scripts that integrate dependency library lookup and linking logic.

[0069] For example, Windows to Linux code migration can include: (1) Input code #include<windows.h> HANDLE hMutex = CreateMutex(NULL, FALSE, "MyMutex"); (2) Code conversion Static analysis identifies CreateMutex, and the query rule base is replaced with pthread_mutex_init.

[0070] Automatically add Linux header files #include<pthread.h> .

[0071] (3) Dependency identification The pthread symbol was detected, and the dependency library libpthread was marked.

[0072] Generate the CMake command: target_link_libraries(... pthread).

[0073] (4) Output code: #include<pthread.h> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER.

[0074] Among them, (1) obtain the native Windows code (such as the mutex creation logic using CreateMutex); (2) identify CreateMutex calls through static analysis, query the built-in rule base (including API mapping tables such as CreateMutex→pthread_mutex_init), automatically replace them with the Linux equivalent implementation, and supplement the header files (such as adding #include).<pthread.h> (3) Detect pthread symbols through dependency identification, mark the dependent library libpthread that needs to be linked, and generate CMake instructions (such as target_link_libraries(... pthread)); (4) Finally output code that is fully adapted to Linux (such as using PTHREAD_MUTEX_INITIALIZER to initialize the mutex). Through API mapping, automatic dependency inference and build instruction generation, the cost of cross-platform porting is significantly reduced.

[0075] Therefore, the method of this disclosure can achieve dynamic mapping of operating system APIs, automatically replace interfaces through a rule base, reduce manual modifications, and shorten code migration time. It can also achieve hybrid dependency analysis, combining static symbol tracking and dynamic loading monitoring to improve dependency identification accuracy. Furthermore, it can build a configuration self-healing mechanism to automatically fix missing dependencies or version conflicts, improving compilation success rate.

[0076] It should be noted that the method of this disclosure embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this disclosure embodiment, and the multiple devices will interact with each other to complete the method described.

[0077] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0078] Based on the same technical concept, corresponding to any of the above embodiments, this disclosure also provides a code conversion device for compiled languages, see [link to relevant documentation]. Figure 6 The code conversion device for compiled languages ​​includes: The acquisition module is used to acquire the first code based on the first platform. A cross-platform code conversion engine is used to convert the first platform elements associated with the first platform in the first code based on a preset mapping rule library to obtain second code based on the second platform; The dependency library auto-identification component is used to identify the dependency libraries in the second code to obtain the corresponding dependency library database; and to automatically install the dependency libraries corresponding to the second platform based on the dependency library database, and generate build script instructions; A smart build configuration generator is used to generate a configuration file and corresponding compilation options for the second platform based on the build script instructions and the dependency libraries. The output module is used to generate code conversion results based on the second code, the configuration file, and the compilation options.

[0079] Specifically, such as Figure 6As shown, the code conversion apparatus for compiled languages ​​provided in this disclosure includes a cross-platform code conversion engine, an automatic dependency library identification component, and an intelligent build configuration generator.

[0080] The cross-platform code transformation engine comprises a static code analysis module, a conditional compilation optimization module, and an API mapping rule base. The static code analysis module parses the AST based on Clang / LLVM, extracting platform-specific elements, such as those related to the operating system. The conditional compilation optimization module automatically merges code branches from multiple platforms, generating a platform abstraction layer. The API mapping rule base includes built-in operating system interface conversion rules and compiler macro adaptation rules, and supports user-defined extensions.

[0081] The dependency auto-identification component comprises four modules: symbol tracing, dynamic loading analysis, package manager integration, and version conflict resolution. The symbol tracing module analyzes undefined symbols using an LLVM intermediate representation and maps them back to dynamic libraries (e.g., pthread_create → libpthread.so). The dynamic loading analysis module automates the identification and tracing of dynamic dependencies. The package manager integration module interfaces with package management tools such as Conan / vcpkg, automatically installing dependency libraries and generating build script instructions based on the target platform. The version conflict resolution module builds the dependency graph and recommends cross-platform compatible versions.

[0082] The intelligent build configuration generator consists of two modules: multi-platform build script generation and container support. The multi-platform build script generation module automatically generates CMake or Makefile scripts based on the target platform, injecting platform-specific compilation options. The containerization support module supports generating Dockerfiles to isolate the compilation environment and ensure dependency consistency.

[0083] In some embodiments, the cross-platform code transformation engine includes: The static code analysis module is used to parse the first code and obtain an abstract syntax tree; The platform element extraction module is used to extract the first platform element from the first code based on the abstract syntax tree; the first platform element includes API calls, compiler macros, and file paths. The code conversion module is used to match the mapping rules in the preset mapping rule library with the first platform element, and obtain the second code based on the matching result.

[0084] In some embodiments, the code conversion module includes: The code mapping module is used to transform the first platform element in the first code based on the mapping rule in response to the first platform element matching the first platform element, thereby obtaining a code branch based on the second platform. The conditional compilation optimization module is used to conditionally compile and merge the code branches to obtain the platform abstraction layer; The manual conversion module is used to convert the first platform element in the code to obtain manually converted code. The code output module is used to obtain the second code based on the platform abstraction layer and the manually converted code.

[0085] In some embodiments, the dependency library auto-identification component includes: The symbol tracking module is used to determine the corresponding first dependency library based on the undefined symbols in the code branch; The dynamic loading analysis module is used to execute the second code in a sandbox environment to determine the second dependency library that is dynamically loaded; The dependency library database module is used to determine the dependency library database based on the first dependency library and the second dependency library.

[0086] In some embodiments, the dynamic loading analysis module is further configured to: In response to determining that the second platform is a Linux system, the LD_DEBUG environment variable is obtained to obtain library loading information, and the second dependent library is determined based on the library loading information; In response to determining that the second platform is a macOS system, the DTrace script monitors dlopen or dlsym calls to identify the second dependent library; In response to determining that the second platform is a Windows system, the LoadLibrary call or GetProcAddress call is intercepted via API hook to identify the second dependency library.

[0087] In some embodiments, the apparatus further includes: The dependency graph module is used to construct a dependency graph based on the first dependency library and the second dependency library; The version conflict resolution module is used to update the conflicting dependency library to a compatible version in response to the detection of a version conflict in the dependency library database.

[0088] In some embodiments, the apparatus further includes a containerization support module for: A Dockerfile is generated based on the configuration file, and a Docker image is generated based on the Dockerfile. Running the Docker image yields the corresponding Docker container; The code transformation result is run in the Docker container to isolate the compilation environment.

[0089] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0090] The apparatus of the above embodiments is used to implement the code conversion method for the corresponding compiled language in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0091] Based on the same technical concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to execute the code conversion method for compiled languages ​​as described in any of the above embodiments.

[0092] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0093] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the code conversion method for compiled languages ​​as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0094] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0095] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0096] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0097] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A code conversion method for compiled languages, characterized in that, include: Obtain the first code based on the first platform; Based on a preset mapping rule base, the first platform elements associated with the first platform in the first code are transformed to obtain the second code based on the second platform; The second code is subjected to dependency library identification to obtain the corresponding dependency library database; The dependency libraries corresponding to the second platform are automatically installed based on the dependency library database, and build script instructions are generated. Based on the build script instructions and the dependency libraries, generate the configuration file and corresponding compilation options for the second platform; The code conversion result is generated based on the second code, the configuration file, and the compilation options.

2. The method according to claim 1, characterized in that, Based on a preset mapping rule base, the first platform elements associated with the first platform in the first code are transformed to obtain second code based on the second platform, including: The first code is parsed to obtain an abstract syntax tree; The first platform element is extracted from the first code based on the abstract syntax tree; the first platform element includes API calls, compiler macros, and file paths. The mapping rules in the preset mapping rule library are matched with the first platform element, and the second code is obtained based on the matching result.

3. The method according to claim 2, characterized in that, The mapping rules in the preset mapping rule base are matched with the first platform element, and the second code is obtained based on the matching result, including: In response to the first platform element matching the mapping rule, the first platform element in the first code is transformed based on the mapping rule to obtain a code branch based on the second platform; and the code branch is conditionally compiled and merged to obtain a platform abstraction layer. In response to the mismatch between the first platform element and the interface mapping rule, the first platform element in the first code is manually converted to obtain manually converted code; The second code is obtained based on the platform abstraction layer and the manually converted code.

4. The method according to claim 3, characterized in that, The second code is subjected to dependency library identification to obtain the corresponding dependency library database, including: The first dependency library is determined based on the undefined symbols in the code branch; The second code is executed in a sandbox environment to determine the dynamically loaded second dependency library; The dependency library database is determined based on the first dependency library and the second dependency library.

5. The method according to claim 4, characterized in that, The second code is executed in a sandbox environment to determine the dynamically loaded second dependency library, including: In response to determining that the second platform is a Linux system, the LD_DEBUG environment variable is obtained to obtain library loading information, and the second dependent library is determined based on the library loading information; In response to determining that the second platform is a macOS system, the DTrace script monitors dlopen or dlsym calls to identify the second dependent library; In response to determining that the second platform is a Windows system, the LoadLibrary call or GetProcAddress call is intercepted via API hook to identify the second dependency library.

6. The method according to claim 4, characterized in that, Also includes: Construct a dependency graph based on the first dependency library and the second dependency library; In response to the detection of a version conflict dependency in the dependency database, the version conflict dependency is updated to a compatible version dependency.

7. The method according to claim 1, characterized in that, Also includes: A Dockerfile is generated based on the configuration file, and a Docker image is generated based on the Dockerfile. Running the Docker image yields the corresponding Docker container; The code transformation result is run in the Docker container to isolate the compilation environment.

8. A code conversion device for compiled languages, characterized in that, include: The acquisition module is used to acquire the first code based on the first platform. A cross-platform code conversion engine is used to convert the first platform elements associated with the first platform in the first code based on a preset mapping rule library to obtain second code based on the second platform; The dependency library auto-identification component is used to identify the dependency libraries in the second code and obtain the corresponding dependency library database; And automatically install the dependency libraries corresponding to the second platform based on the dependency library database, and generate build script instructions; A smart build configuration generator is used to generate a configuration file and corresponding compilation options for the second platform based on the build script instructions and the dependency libraries. The output module is used to generate code conversion results based on the second code, the configuration file, and the compilation options.

9. The apparatus according to claim 8, characterized in that, The cross-platform code conversion engine includes: The static code analysis module is used to parse the first code and obtain an abstract syntax tree; The platform element extraction module is used to extract the first platform element from the first code based on the abstract syntax tree; the first platform element includes API calls, compiler macros, and file paths. The code conversion module is used to match the mapping rules in the preset mapping rule library with the first platform element, and obtain the second code based on the matching result.

10. The apparatus according to claim 9, characterized in that, The code conversion module includes: The code mapping module is used to transform the first platform element in the first code based on the mapping rule in response to the first platform element matching the first platform element, thereby obtaining a code branch based on the second platform. The conditional compilation optimization module is used to conditionally compile and merge the code branches to obtain the platform abstraction layer; The manual conversion module is used to convert the first platform element in the code to obtain manually converted code. The code output module is used to obtain the second code based on the platform abstraction layer and the manually converted code.

11. The apparatus according to claim 10, characterized in that, The dependency library automatic identification component includes: The symbol tracking module is used to determine the corresponding first dependency library based on the undefined symbols in the code branch; The dynamic loading analysis module is used to execute the second code in a sandbox environment to determine the second dependency library that is dynamically loaded; The dependency library database module is used to determine the dependency library database based on the first dependency library and the second dependency library.

12. The apparatus according to claim 11, characterized in that, The dynamic loading analysis module is also used for: In response to determining that the second platform is a Linux system, the LD_DEBUG environment variable is obtained to obtain library loading information, and the second dependent library is determined based on the library loading information; In response to determining that the second platform is a macOS system, the DTrace script monitors dlopen or dlsym calls to identify the second dependent library; In response to determining that the second platform is a Windows system, the LoadLibrary call or GetProcAddress call is intercepted via API hook to identify the second dependency library.

13. The apparatus according to claim 12, characterized in that, Also includes: The dependency graph module is used to construct a dependency graph based on the first dependency library and the second dependency library; The version conflict resolution module is used to update the conflicting dependency library to a compatible version in response to the detection of a version conflict in the dependency library database.

14. The apparatus according to claim 8, characterized in that, It also includes a containerization support module for: A Dockerfile is generated based on the configuration file, and a Docker image is generated based on the Dockerfile. Running the Docker image yields the corresponding Docker container; The code transformation result is run in the Docker container to isolate the compilation environment.

15. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in any one of claims 1 to 7.

16. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

Images