Cross-platform compiling method and device, electronic equipment and storage medium

Abstract

The application relates to a cross-platform compiling method and device, electronic equipment and a storage medium. The method comprises the following steps: obtaining a source code file to be compiled, the source code file containing at least one symbol declaration and a plurality of conditional compiling code blocks; determining a target operating system specified for this time of compiling and a target platform macro identifier corresponding to the target operating system from a plurality of preset operating systems; preprocessing the symbol declaration based on a preprocessing rule defined by a target conditional compiling code block, to obtain a preprocessed source code file corresponding to the target operating system; and compiling and linking the preprocessed source code file to generate a target code file for the target operating system. The method generates a preprocessed source code file matched with the target operating system, so that the same set of source code can adapt to the compiling requirements of different preset operating systems, thereby avoiding the problem of maintaining a plurality of sets of source code due to differences between operating systems.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a cross-platform compilation method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the fields of embedded systems, automotive software, and cross-platform software development, the same functional module (such as a diagnostic protocol stack, sensor driver, or communication middleware) typically needs to be deployed on multiple operating system platforms, such as Android (for in-vehicle systems or mobile terminals), iOS (for mobile diagnostic apps), Windows (for host computers), and various real-time operating systems (RTOS). Due to differences in interface specifications, linking rules, dynamic library export mechanisms, and namespace management across different platforms, related technologies often require maintaining different versions of source code for different platforms, leading to code duplication, high maintenance costs, and the potential introduction of inconsistencies and defects. Summary of the Invention

[0003] This application provides a cross-platform compilation method, apparatus, electronic device, and storage medium to solve the above-mentioned problems.

[0004] To achieve the above objectives, according to a first aspect of this application, a cross-platform compilation method is provided, the method comprising: Obtain the source code file to be compiled. The source code file contains at least one symbol declaration and multiple conditional compilation code blocks. The multiple conditional compilation code blocks are associated with platform macro identifiers corresponding to different preset operating systems, and are used to define preprocessing rules for the symbol declarations to adapt to different preset operating systems. From multiple preset operating systems, determine the target operating system specified for this compilation, and the target platform macro identifier corresponding to the target operating system; Based on the target platform macro identifier, determine the target conditional compilation block associated with the target platform macro identifier from multiple conditional compilation blocks; Based on the preprocessing rules defined in the target conditional compilation code block, the symbol declarations are preprocessed to obtain a preprocessed source code file corresponding to the target operating system. The preprocessed source code file is compiled and linked to generate target code files for the target operating system.

[0005] Optionally, the preprocessing of the symbol declarations based on the preprocessing rules defined by the target conditional compilation code block to obtain a preprocessed source code file corresponding to the target operating system includes: Based on the preprocessing rules defined by the target conditional compilation information, the symbol declarations are preprocessed to change the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, thereby obtaining the preprocessed source code file.

[0006] Optionally, the preprocessing rules defined based on the target conditional compilation information are used to preprocess the symbol declarations, thereby changing the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, to obtain the preprocessed source code file, including: When the target operating system is detected to be Android, the symbol declaration is encapsulated in the code block corresponding to the predefined link modifier to change the linking form of the symbol declaration, thereby obtaining the preprocessed source code file. When the target operating system is detected to be a non-Android operating system, the linking format of the symbol declaration is kept as the default linking format to obtain the preprocessed source code file; The predefined linker is used to control the compilation process so that the symbol names corresponding to the symbol declarations within the code block are not changed.

[0007] Optionally, the preprocessing rules defined based on the target conditional compilation information are used to preprocess the symbol declarations, thereby changing the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, to obtain the preprocessed source code file, including: When the target operating system is detected to be iOS, at least some of the symbol declarations are selectively restricted to the scope of the target namespace to obtain the preprocessed source code file; When the target operating system is detected to be a non-iOS operating system, the namespace of the symbol declaration is kept as the global namespace to obtain the preprocessed source code file.

[0008] Optionally, at least a portion of the symbol declarations include symbol declarations related to the target vehicle, and the method further includes: Based on the attribute information of the target vehicle and the function type corresponding to at least part of the symbol declaration, the target namespace corresponding to the target vehicle is determined by a preset naming rule; The attribute information includes at least one of vehicle model and manufacturer identifier, and the function type includes at least one of encryption algorithm, compression / decompression algorithm or diagnostic algorithm.

[0009] Optionally, the at least one symbol declaration includes a target symbol declaration obtained from an exported macro identifier declaration representing exported attributes. The preprocessing of the symbol declaration based on the preprocessing rules defined by the target conditional compilation information, thereby changing the namespace, linking form, or exported attributes of the symbol corresponding to the symbol declaration in the target code file, to obtain the preprocessed source code file, includes: When the target operating system is detected to be a Windows operating system, the exported macro identifiers in the target symbol declaration are expanded into predefined exported declaration modifiers to obtain the expanded target symbol declaration; or... When the target operating system is detected to be a non-Windows operating system, the exported macro identifier in the target symbol declaration is expanded to an empty or specified identifier to obtain the expanded target symbol declaration; Based on the expanded target symbol declaration, the preprocessed source code file is obtained; The export declaration modifier is used to instruct that the symbol name corresponding to the target symbol declaration be recorded in the export symbol table of the dynamic link library, so that external programs can access the implementation code corresponding to the symbol name in the export symbol table.

[0010] Optionally, the symbol declaration includes at least one of a function declaration, a variable declaration, or a class declaration.

[0011] According to a second aspect of this application, embodiments of this application also provide a cross-platform compilation apparatus, the apparatus comprising: The acquisition module is used to acquire the source code file to be compiled. The source code file contains at least one symbol declaration and multiple conditional compilation code blocks. The multiple conditional compilation code blocks are associated with platform macro identifiers corresponding to different preset operating systems, and are used to define preprocessing rules for the symbol declarations to adapt to different preset operating systems. The first determining module is used to determine the target operating system specified for this compilation and the target platform macro identifier corresponding to the target operating system from multiple preset operating systems; The second determining module is used to determine the target conditional compilation code block associated with the target platform macro identifier from multiple conditional compilation code blocks based on the target platform macro identifier. The preprocessing module is used to preprocess the symbol declarations based on the preprocessing rules defined in the target conditional compilation code block, so as to obtain a preprocessed source code file corresponding to the target operating system. The compilation module is used to compile and link the preprocessed source code files to generate target code files for the target operating system.

[0012] According to a third aspect of this application, embodiments of this application also provide an electronic device, comprising: A memory on which computer programs are stored; A processor is configured to execute the computer program in the memory to implement the steps of any of the methods provided in the embodiments of this application.

[0013] According to a fourth aspect of this application, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the methods provided in embodiments of this application.

[0014] Some embodiments of this application include at least the following beneficial effects: by introducing platform macro identifiers corresponding to different preset operating systems and associating multiple conditional compilation code blocks with these platform macro identifiers respectively, the same source code file can automatically adapt to different preprocessing rules according to the type of the target operating system. During the compilation process, the system first determines the target operating system specified for this compilation and its corresponding target platform macro identifier, then accurately selects the target conditional compilation code block associated with it, and preprocesses the symbol declarations in the source code based on the preprocessing rules defined in this information, generating a preprocessed source code file that matches the target operating system. This allows the same set of source code to adapt to the compilation requirements of different preset operating systems, thereby avoiding the problem of maintaining multiple sets of source code due to differences in operating systems.

[0015] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

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

[0017] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings, wherein the same reference numerals in the following description denote the same parts.

[0018] Figure 1 This is an application scenario diagram of a cross-platform compilation method according to some embodiments of this application; Figure 2 This is an exemplary flowchart of a cross-platform compilation method according to some embodiments of this application; Figure 3 This is an exemplary flowchart of yet another cross-platform compilation method according to some embodiments of this application; Figure 4 This is a schematic diagram of the structure of a cross-platform compilation apparatus according to some embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device according to some embodiments of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0020] To facilitate understanding of the implementation schemes provided in this application, the relevant application background of the cross-platform compilation method provided in this application will be explained first.

[0021] The implementation of on-board diagnostic systems on Android, iOS, and Windows platforms faces cross-platform compatibility issues. For example, Android supports compiling C++ source code into .so dynamic libraries, allowing multiple dynamic libraries to coexist without conflicting functions with the same name. iOS platforms typically integrate as static libraries (.a) or frameworks, merging all symbols into the same namespace during linking. This can lead to symbol conflicts if different diagnostic modules (such as NISSAN and RENAULT) have functions with the same name. Windows platforms require the use of `__declspec(dllexport)` to export symbols when generating dynamic link libraries (DLLs), and its export mechanism is incompatible with both Android and iOS platforms. Therefore, the current approach of maintaining three separate sets of C++ code to adapt to each platform results in redundant development, difficulties in version synchronization, frequent symbol conflicts, and poor scalability.

[0022] In view of this, some embodiments of this application provide a cross-platform compilation method. By defining platform-related macros in the compilation configuration and combining a unified export macro (also known as) and namespace encapsulation strategy, the same set of C++ source code can be compiled to generate library files suitable for Android (.so), iOS (.a or Framework), and Windows (DLL) without modifying the source code. On the iOS platform, by assigning corresponding namespaces to diagnostic modules of different car models or brands, symbols are effectively isolated, and symbol name conflicts during linking are completely avoided. This achieves the effect of the same set of source code being universal across multiple platforms, which helps to reduce maintenance costs and improve system consistency and scalability.

[0023] Figure 1 This is an application scenario diagram of a cross-platform compilation method according to some embodiments of this application.

[0024] The implementing entity of the technical solution in this application embodiment can be an electronic device, which may include a cross-platform compilation device. This cross-platform compilation device can be implemented in hardware and / or software, and can be configured in any electronic device with network communication capabilities. The electronic device can be a server, a terminal, or other similar device.

[0025] The implementing entity of the technical solution in this application embodiment can be a compilation device. This compilation device can be dedicated hardware, an embedded system, or a hardware-software co-working platform, and can be implemented in the form of hardware circuits, firmware programs, and / or software modules. It is applicable to any computing device with code building, platform recognition, and symbol management capabilities. This compilation device can be a development terminal for vehicle diagnostics, an engineering debugging terminal, a mobile intelligent terminal, or an automated build server deployed in the cloud or a telematics control unit (TCU) integrated into the vehicle's electronic architecture.

[0026] like Figure 1 As shown, the method provided in the embodiments of this application can be applied to, for example... Figure 1 In the application scenario shown, the build environment includes a terminal and a server. The terminal and server establish a data connection via a communication network, which includes, but is not limited to, cellular mobile networks (such as 4G / 5G), Wi-Fi LANs, or wired Ethernet. Simultaneously, the terminal performs conditional preprocessing on the source code locally and generates adapted intermediate code files based on the specified target operating system. These intermediate code files are then used for subsequent compilation and linking to generate executable target code files or library files for the corresponding platform.

[0027] In some embodiments, the terminal can be a fixed build node, such as a compilation server configured in an automotive electronics R&D institution or an OEM (Original Equipment Manufacturer) CI / CD pipeline; it can also be a portable development device, such as a laptop, industrial tablet, or smartphone supporting the Android NDK / Xcode toolchain used by engineers. A build engine runs within the terminal to execute the processes described in the embodiments of this application.

[0028] In some embodiments, after the build engine starts, it first loads the C++ source code file to be compiled. This source code file contains multiple symbol declarations (such as functions, variables, or classes) and conditional compilation instructions (also known as conditional compilation code blocks, etc.) associated with different operating systems. The conditional compilation instructions include at least the ANDROID_OS macro for the Android platform, the IOS_OS macro for the iOS platform, and the WINDOWS macro for the Windows platform, used to control the export attributes, linking forms, or namespace scope of symbols.

[0029] The server can store a unified source code library for diagnostic functions, namespace mapping tables for various car brands, and platform adaptation rule sets.

[0030] After obtaining the target platform macro identifier for the target operating system, the engine-based target platform macro identifier is constructed, and the corresponding conditional compilation instructions are executed to perform differentiated preprocessing on symbol declarations. For example, on the iOS platform, the diagnostic functions for Nissan vehicles are automatically limited to the NISSAN::DIAGCALC namespace; on the Android platform, the diagnostic functions are wrapped in extern "C" to retain the original symbol names; and on the Windows platform, the export macro of the diagnostic functions is expanded to __declspec(dllexport) to register DLL exports. Subsequently, platform-specific intermediate code files (also known as preprocessed source code files) are generated based on the preprocessing results, and the corresponding toolchain is called to complete compilation and linking, outputting target code files in .so, .a / Framework, or .dll formats.

[0031] Conditional compilation directives can be implemented by preprocessor directives (such as #ifdef and #define). Their control logic is driven by the build script or CMake / Xcode / MSBuild configuration. They can dynamically adjust the export attributes, linking forms, and scope of symbols without modifying the function body.

[0032] It is important to note that the application scenarios for cross-platform compilation methods are provided for illustrative purposes only and are not intended to limit the scope of this specification. Those skilled in the art can make various changes and modifications based on the descriptions in this specification. For example, application scenarios may also include databases, information sources, etc. Furthermore, application scenarios may be implemented on other devices to achieve similar or different functionalities. However, these changes and modifications will not depart from the scope of this specification.

[0033] Figure 2 This is an exemplary flowchart of a cross-platform compilation method according to some embodiments of this application. In some embodiments, process 200 may be executed on an electronic device. Figure 2As shown, process 200 includes the following steps.

[0034] Step 210: Obtain the source code file to be compiled. The source code file contains at least one symbol declaration and multiple conditional compilation code blocks.

[0035] Among them, multiple conditional compilation code blocks are associated with platform macro identifiers corresponding to different preset operating systems, which are used to define preprocessing rules for symbol declarations to adapt to different preset operating systems.

[0036] Source code files refer to a set of raw program files used to build a target executable program or library. For example, source code files can include header files (such as .h or .hpp files) and code implementation files (such as .c or .cpp files). The header file contains at least one symbol declaration, which is a syntactic structure used to define entities that can be referenced by external programs or internal modules. For example, `int OdxCalcFromScriptEx(char*, char*, unsigned char)` is a symbol declaration for a function.

[0037] Conditional compilation blocks refer to control logic embedded in source code in the form of preprocessor directives (such as #ifdef, #ifndef, #if, etc.) or macro definitions. They are used to selectively include or exclude parts of code during the preprocessing stage based on a specific compilation environment. In this embodiment, each conditional compilation block is associated with a platform macro identifier corresponding to a preset operating system (e.g., Android, iOS, Windows, etc.). The platform macro identifier is a preprocessor macro defined by compilation configuration parameters during the system configuration stage, used to uniquely identify the current target operating system platform (hereinafter referred to as the target operating system). For example, the platform macro identifier "IOS_OS" is defined in the Xcode project configuration for the iOS platform, "ANDROID_OS" is defined in the Android NDK build script (such as CMakeLists.txt or Android.mk), and "WINDOWS" is defined in the Visual Studio project properties for the Windows platform.

[0038] Here, ANDROID_OS identifies the Android platform, IOS_OS identifies the iOS platform, and WINDOWS identifies the Windows platform. The platform macro identifier is used to trigger the associated preprocessing rules.

[0039] Preprocessing rules refer to code transformation strategies set for the symbols that symbol declarations need to satisfy under different operating systems, including but not limited to: whether to wrap them in an extern "C" block to control C++ name mangling, whether to limit them to a specific namespace to isolate symbols, and whether to expand them into export declaration modifiers such as __declspec(dllexport).

[0040] In some embodiments, a symbol declaration includes at least one of a function declaration, a variable declaration, or a class declaration.

[0041] Step 220: Determine the target operating system specified for this compilation and the target platform macro identifier corresponding to the target operating system from multiple preset operating systems.

[0042] The target operating system refers to the operating system platform that the developer or automated build system expects to generate in a particular build task for the executable code or library files. For example, when developing an Android version for an onboard diagnostic app, the target operating system is Android; when generating a Windows desktop application for a repair shop tool, the target operating system is Windows.

[0043] The target platform macro identifier refers to the predefined macro name corresponding to the target operating system mentioned above.

[0044] In some embodiments, the target platform macro identifier can be specified by the user through build scripts, command-line arguments, project settings, or a graphical configuration interface, or it can be automatically generated by the continuous integration (CI) system based on the target operating system to be deployed.

[0045] Step 230: Based on the target platform macro identifier, determine the target conditional compilation block associated with the target platform macro identifier from multiple conditional compilation blocks.

[0046] The target conditional compilation block refers to the control logic in all predefined conditional compilation blocks that matches the target platform macro identifier corresponding to the current build task.

[0047] In an optional implementation, when the build system specifies IOS_OS as the target platform macro identifier, the preprocessor executes the code block starting with #ifdef IOS_OS when scanning the source code files, and ignores code blocks corresponding to other operating system platforms (such as #ifdef WINDOWS). Thus, the preprocessing rules associated with IOS_OS, such as namespace encapsulation and no export modifiers, are determined as the target conditional compilation code block used in this compilation.

[0048] Step 240: Based on the preprocessing rules defined in the target conditional compilation code block, preprocess the symbol declarations to obtain the preprocessed source code file corresponding to the target operating system.

[0049] In an optional implementation, when the target operating system is Android, the preprocessing rules include: wrapping specific function declarations in an extern "C" block to prevent the C++ compiler from manipulating function names, ensuring that the generated target symbol names are consistent with the corresponding symbol names in the source code; when the target operating system is iOS, the preprocessing rules include: encapsulating symbol declarations related to the target vehicle into a namespace dynamically generated by the vehicle model, while preserving the scope of general interface functions in the global namespace to achieve symbol isolation; when the target operating system is Windows, the preprocessing rules include: inserting or replacing __declspec(dllexport) or equivalent macros before function or variable declarations that need to be exported, so that the generated dynamic link library (DLL) can expose the symbol names of the function or variable declarations to third-party applications.

[0050] Understandably, the above preprocessing operations are performed by the standard C++ preprocessor during the preprocessing phase of the build process. After determining the target platform macro identifier, the preprocessor identifies the conditional compilation code blocks in the source code associated with the target platform macro identifier and outputs intermediate code files adapted to the target operating system platform, i.e., the preprocessed source code files.

[0051] Step 250: Compile and link the preprocessed source code files to generate target code files for the target operating system.

[0052] Object code files are binary files generated through compilation and linking that can be loaded or called on the target operating system. The format of an object code file depends on the target operating system's runtime environment. For example, when the target operating system is Android, the object code file is a dynamic library (.so file); when the target operating system is iOS, the object code file can be a static library (.a) or a dynamic framework (Framework); and when the target operating system is Windows, the object code file is a dynamic link library (.dll file). Object code files all contain adapted function symbols that can be called by upper-level applications (such as Java / Kotlin, Swift / Objective-C, or C# programs).

[0053] In some embodiments of this application, because operating system adaptation is performed during the preprocessing stage, the compilation and linking processes require no additional manual intervention or configuration, improving build efficiency and stability. In diagnostic scenarios where the target operating system is iOS and there are multiple brands, multiple diagnostic modules can coexist in the same static library set because symbols are isolated through namespaces, avoiding symbol conflicts that occur in related methods. Simultaneously, since all platforms share the same set of diagnostic logic source code, version consistency can be ensured, thereby avoiding functional deviations or maintenance delays. The final generated target code file not only meets the specifications of each operating system but also possesses good compatibility and operational reliability, facilitating the cross-platform deployment of the vehicle diagnostic system.

[0054] In some embodiments, symbol declarations are preprocessed based on the preprocessing rules defined in the target conditional compilation code block to obtain a preprocessed source code file corresponding to the target operating system, including: Based on the preprocessing rules defined by the target conditional compilation information, symbol declarations are preprocessed, thereby changing the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, resulting in a preprocessed source code file.

[0055] Linking conventions refer to the language linking specifications used by symbols during the compilation and linking phase, such as the C language linking specification (extern "C") or the C++ default linking specification. The C language linking specification is used to suppress name mangling to ensure that symbol names remain stable in binary. Export attributes refer to whether a symbol is marked as externally visible, which is declared in dynamic libraries (such as .DLL) using keywords such as __declspec(dllexport).

[0056] In one specific embodiment, after determining the target platform macro identifier (such as IOS_OS, ANDROID_OS, or WINDOWS), the preprocessor compiles code blocks according to the associated target conditions, modifying each symbol declaration in the source code. For example, if the target operating system is iOS, namespace encapsulation is enabled, causing the function OdxCalcFromScriptEx, located in the global namespace scope, to be relocated to the NISSAN::DIAGCALC namespace, and its symbol name becomes NISSAN::DIAGCALC::OdxCalcFromScriptEx, thus isolating it from functions with the same name in other brand diagnostic modules. If the target operating system is Android, the function declaration is wrapped in an extern "C" { …} structure, ensuring that the symbol name of the function in the generated .so library is not modified by C++ names, facilitating the Java layer to find and call it using a fixed string via the JNI mechanism. If the target operating system is Windows, __declspec(dllexport) is added before the function declaration, ensuring that it is correctly exported when the DLL is generated, allowing external applications to dynamically load and use it. The above preprocessing can be applied individually or in combination to the same symbol declaration, depending on the actual needs of each operating system.

[0057] In some embodiments, symbol declarations are preprocessed based on preprocessing rules defined by target conditional compilation information, thereby changing the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, resulting in a preprocessed source code file, including: When the target operating system is detected to be Android, the symbol declarations are encapsulated in the code block corresponding to the predefined link modifiers to change the linking form of the symbol declarations and obtain the preprocessed source code file. When the target operating system is detected to be a non-Android operating system, the symbol declaration linking format is kept to the default linking format in order to obtain the preprocessed source code file; Among them, the predefined linker is used to control the compilation process so that the symbol names corresponding to the symbol declarations within the code block are not changed.

[0058] Linking refers to how the compiler handles symbol names when generating object code files. During standard C++ compilation, the compiler performs name mangling on function names. This involves generating a unique, unreadable internal symbol name based on information such as the function's return type, parameter list, class, and namespace to support function overloading and scope isolation. However, on the Android platform, when the Java or Kotlin layer calls native C++ functions via JNI (Java Native Interface), the JNI mechanism relies on searching for the string corresponding to the raw, unmangled function name in the dynamic library (.so file). If the symbol name is mangled, the Java or Kotlin layer cannot locate the correct native function, leading to an error.

[0059] In an alternative embodiment, the predefined linker can be represented as the `extern "C"` linker in the C++ language standard. `extern "C"` is not a user-defined macro or keyword, but rather a linker specification directive in C++ that instructs the compiler to use the C language's linker specification for the enclosed code block. Under the C language's linker specification, the compiler does not name-manage function names, but instead preserves their original symbol names as exported symbols. For example, when the build system detects that the current target operating system is the Android operating system, i.e., after detecting the target platform macro identifier `ANDROID_OS`, the preprocessor will execute the associated target conditional compilation code block, placing the relevant symbol declarations (such as diagnostic calculation functions) within the `extern "C"{...}` code block, for example: In some embodiments, after the above preprocessing, the symbolic name of the diagnostic calculation function in the generated .so library is OdxCalcFromScriptEx, which is consistent with the name expected by JNI registration and can be called by the Java / Kotlin layer.

[0060] In some embodiments, for non-Android operating systems (such as iOS or Windows), since their upper-level calling mechanisms do not depend on the original symbol names, there is no need to suppress name mangling. In this case, symbol declarations retain the default C++ linking form, allowing the compiler to perform name mangling normally.

[0061] Figure 3 This is an exemplary flowchart illustrating yet another cross-platform compilation method according to some embodiments of this application. In some embodiments, process 300 may be executed on an electronic device. Figure 3 As shown, process 300 includes the following steps.

[0062] In some embodiments, symbol declarations are preprocessed based on preprocessing rules defined by target conditional compilation information, thereby changing the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, resulting in a preprocessed source code file, including: Step 310: When the target operating system is detected to be iOS, at least some symbol declarations are selectively restricted to the scope of the target namespace to obtain the preprocessed source code file. Step 320: When the target operating system is detected to be a non-iOS operating system, keep the namespace of the symbol declaration as the global namespace to obtain the preprocessed source code file.

[0063] A target namespace is a unique namespace assigned to a specific diagnostic module (e.g., corresponding to a particular car brand or model) on the iOS platform. Different target namespaces correspond to different names, such as NISSAN::DIAGCALC or RENAULT::DIAGCALC. This namespace can be predefined by compiler configuration parameters or macro parameters and injected into the source code through conditional compilation blocks. A global namespace is the default scope to which all symbols belong when no target namespace is specified. Within this default scope, all symbol names are unique.

[0064] In some embodiments, when the build system detects that the current target operating system is iOS, i.e., after detecting the target platform macro identifier IOS_OS, the preprocessor will execute the associated target conditional compilation code block, wrapping the specific symbol declaration within the target namespace. For example, in the header or source file, the original function declaration is: int_EXPORT OdxCalcFromScriptEx(char* bResult, char* Script, unsigned charPrecision).

[0065] In some embodiments, on the iOS platform, the function declaration is converted to: using a conditional compilation block. namespace NISSAN { namespace DIAGCALC { int_EXPORTOdxCalcFromScriptEx(char* bResult, char* Script, unsigned char Precision),}}.

[0066] In some embodiments, when the target operating system is detected to be a non-iOS operating system (such as Android, Windows, or Linux), the namespace of all symbol declarations is kept as the global namespace, that is, no additional namespace restrictions are introduced.

[0067] In some embodiments, certain functions need to remain in the global namespace, such as public interfaces or callback functions that interact with third-party libraries. For such functions, since they are used by multiple vehicle models and their symbols do not belong to a specific model, the namespace is not limited to a particular model; the declaration format of the global namespace remains consistent with the original third-party library. For example, this can be controlled through macros or header file hierarchical structure, encapsulating only vehicle-specific diagnostic functions into the corresponding vehicle model's namespace, while keeping public third-party interfaces in the global namespace. Each vehicle model's diagnostic module only needs to include the corresponding header file.

[0068] In some embodiments, at least a portion of the symbol declaration includes symbol declarations related to the target vehicle, and the method further includes: Based on the target vehicle's attribute information and at least some of the symbol declarations corresponding to the function types, the target namespace corresponding to the target vehicle is determined by using preset naming rules. The attribute information includes at least one of the vehicle model and manufacturer identification, and the function type includes at least one of the encryption algorithm, compression / decompression algorithm, or diagnostic algorithm.

[0069] Attribute information refers to relevant information used to identify a target vehicle, including but not limited to at least one of the following: vehicle model (e.g., Model_X, EV200, etc.), manufacturer identification (e.g., BYD, NISSAN, etc.), or hardware platform type (e.g., a cockpit domain controller based on Qualcomm SA8155P, a body control module based on NXP S32K). In some embodiments, attribute information may be determined based on vehicle configuration files, compilation configuration parameters, or the Vehicle Identification Number (VIN).

[0070] At least partial symbol declarations refer to declarations of specific functions, variables, or classes that need to be encapsulated within a namespace in the source code, and these declarations correspond to specific vehicle-related program entities. Function type is a classification of the business capabilities implemented by the at least partial symbol declarations, including at least one of the following: communication protocol type (e.g., CAN FD, DoIP, Ethernet AVB), sensor drive type (e.g., millimeter-wave radar drive), or algorithm type (e.g., diagnostic algorithms such as OBD-II fault code parsing, ADAS calibration algorithms, encryption algorithms, compression / decompression algorithms, etc.).

[0071] The default naming convention is a predefined string composition logic used to map vehicle attribute information and function types to unique identifiers in the C++ namespace. For example, the default naming convention could adopt a hierarchical structure of manufacturer identifier_function type, such as NISSAN::DIAGCALC.

[0072] In some embodiments, at least one symbol declaration includes a target symbol declaration obtained from a macro identifier declaration representing derived attributes. Based on preprocessing rules defined by the target conditional compilation information, the symbol declaration is preprocessed to change the namespace, linking form, or derived attributes of the symbol corresponding to the symbol declaration in the target code file, resulting in a preprocessed source code file, including: When the target operating system is detected to be Windows, the macro identifiers in the target symbol declaration are expanded into predefined export modifiers to obtain the expanded target symbol declaration; or... When the target operating system is detected to be a non-Windows operating system, the third macro identifier in the target symbol declaration is expanded to an empty or specified identifier to obtain the expanded target symbol declaration; Based on the expanded target symbol declaration, the preprocessed source code file is obtained; The export modifier is used to instruct that the symbol name corresponding to the target symbol declaration be recorded in the export symbol table of the dynamic link library, so that external programs can access the implementation code corresponding to the symbol name in the export symbol table.

[0073] Macro identifiers are predefined macros used to mark functions or variables, such as int_EXPORT. A macro identifier can be represented as a placeholder and expanded into a grammatically appropriate structure across different operating systems.

[0074] In some embodiments, when the build system detects that the current target operating system is Windows, i.e., after detecting the Windows target platform macro identifier, the preprocessor will execute the associated target conditional compilation code block, that is, expand the macro identifier into a form that includes export modifiers, for example, #define int_EXPORT __declspec(dllexport); while on non-Windows platforms such as Android and iOS, the macro identifier expands into an empty string, such as #define int_EXPORT (i.e., no replacement content). Therefore, in the source code, developers only need to declare functions in a uniform format, such as int_EXPORT OdxCalcFromScriptEx(char* bResult, char* Script, unsigned char Precision), without having to write differentiated declaration statements for different operating system platforms.

[0075] In some embodiments, int_EXPORT is expanded to __declspec(dllexport), so that the function declaration actually becomes __declspec(dllexport) OdxCalcFromScriptEx(...). The __declspec(dllexport) instruction tells the linker to record the symbolic name of the function in the DLL's export symbol table when generating the dynamic link library (DLL), so that external programs can access its implementation code.

[0076] In some embodiments, when the target operating system is detected to be a non-Windows operating system (such as Android or iOS), int_EXPORT is expanded to an empty string, and the function declaration remains in the ordinary C++ function declaration form, OdxCalcFromScriptEx(...).

[0077] In some embodiments, preprocessing includes at least one of the following: Macro expansion operations can be used to modify symbol declarations to be target namespace-qualified symbol declarations, and / or restrict the implementation code corresponding to the symbol declarations to the scope of the target namespace; The symbol declaration is modified to have a linker identifier by macro expansion, and / or the implementation code corresponding to the symbol declaration is encapsulated in the code block corresponding to the linker identifier. The target symbol declaration is adjusted to a symbol declaration with exported attributes through macro expansion.

[0078] In one specific implementation, the control of namespace constraints and linkage in symbol declarations can be achieved in several ways. For example, a series of control macros can be predefined in the header file. These control macros can expand into different replacement contents depending on the target operating system. For instance, control macros for enabling and disabling namespaces can be defined. On the iOS platform, the control macro for enabling a namespace is: `#define BEGIN_DIAG_NAMESPACE namespaceNISSAN { namespace DIAGCALC {;` and the control macro for disabling a namespace is: `#define END_DIAG_NAMESPACE}}`. Similarly, on non-iOS platforms, the control macro for enabling a namespace is: `#define BEGIN_DIAG_NAMESPACE`, and the control macro for disabling a namespace is: `#define END_DIAG_NAMESPACE`. As another example, control macros for linkage can also be defined. On the Android platform, the macro for starting linkage is: `#define BEGIN_EXTERN_C extern "C" {;` and the macro for ending linkage is: `#define END_EXTERN_C}`. On non-Android platforms, the macro that controls the start of the linking sequence is: #define BEGIN_EXTERN_C; the macro that controls the end of the linking sequence is: #define END_EXTERN_C.

[0079] In another alternative implementation, conditional compilation directives are used in the source code to wrap the implementation code corresponding to a symbol declaration within the corresponding scope or code block. For example, when IOS_OS is detected, the implementation code corresponding to the function is wrapped within namespace NISSAN { namespace DIAGCALC { ...}}; when ANDROID_OS is detected, the implementation code corresponding to the function is wrapped within extern "C" { ...}.

[0080] For example, on the iOS platform, the namespace scope is opened before a function using the directive #ifdef IOS_OS, and closed after the function using the directive #endif; similarly, on the Android platform, the code block of the linker specification is opened before a function using the directive #ifdef ANDROID_OS, and closed after the function using the directive #endif.

[0081] It should be noted that the above description of the process is for illustrative purposes only and does not limit the scope of this specification. Those skilled in the art can make various modifications and changes to the process under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.

[0082] To better understand the above scheme, the cross-platform compilation method will be explained below with a specific embodiment.

[0083] In the build system, corresponding platform macro identifiers are predefined based on the target operating system to trigger subsequent adaptation logic (also known as preprocessing logic). Specifically, the macro `IOS_OS` is defined in the Xcode project's build settings to identify the current compilation target as the iOS platform; the macro `ANDROID_OS` is defined in the Android.mk or CMakeLists.txt file of the Android NDK project to identify the current compilation target as the Android platform; and the macro `WINDOWS` is set in the Visual Studio project's preprocessor definitions to indicate the current compilation target as the Windows platform.

[0084] To achieve uniformity in interface declarations across multiple platforms, this application introduces an export macro to encapsulate function declarations. This export macro has different expansion forms on different platforms: on Windows, the export macro `int_EXPORT` is defined as `__declspec(dllexport)`; on Android and iOS platforms, `int_EXPORT` is defined as empty (i.e., without any content). Developers can uniformly declare functions in header files using the following form: The function `int_EXPORT OdxCalcFromScriptEx(char* bResult, char* Script, unsignedchar Precision)` is an export macro. When compiling a DLL on Windows, this function declaration expands to a declaration modified with `__declspec(dllexport)`, which is then recorded in the export symbol table. On Android and iOS platforms, the export macro expands to nothing, and the function remains a regular C++ function declaration. Therefore, the interface declaration does not need to be rewritten due to platform differences, and the function implementation code does not need to be modified, improving code consistency and maintainability.

[0085] On the iOS platform, multiple static libraries may contain functions with the same name, which can easily lead to symbol conflicts during the linking phase. Therefore, when a macro definition of `IOS_OS` is detected, function declarations related to specific functions are encapsulated in a vehicle-specific C++ namespace. For example, if the target vehicle is a Nissan model, the symbolic name of the function on the iOS platform is: `NISSAN::DIAGCALC::OdxCalcFromScriptEx`; while on the Android platform, the symbolic name is: `OdxCalcFromScriptEx`.

[0086] On the Android platform, when the Java or Kotlin layer calls native C++ functions via JNI, the function symbol names must remain consistent in the .so dynamic library and must not be C++ name mangling. Therefore, when an ANDROID_OS macro definition is detected, the function declaration is wrapped in an extern "C" linked block; otherwise, the default C++ function declaration form is maintained.

[0087] On the Windows platform, Dynamic Link Libraries (DLLs) need to explicitly mark symbols that allow external programs to call them. This is done by using the export macro `int_EXPORT`, which expands to `__declspec(dllexport)` on Windows, causing functions to be written into the DLL's export table at compile time. External applications can then call these functions.

[0088] In one possible implementation, Script.h and Script.cpp are used as examples to illustrate the specific application of this application's embodiments. In the header file Script.h, all external interface functions (such as OdxCalcFromScriptEx, ReadSmallDataEx, etc.) are declared using a unified int_EXPORT export macro. In the source file Script.cpp, the function implementation code remains unchanged, with conditional compilation directives controlling whether it is wrapped in a namespace scope or an extern "C" block. When compiling on the Windows platform, the export macro expands to __declspec(dllexport), generating a standard DLL; when compiling on the Android platform, the function is wrapped in extern "C", generating a .so dynamic library; when compiling on the iOS platform, the function is confined to a namespace such as NISSAN::DIAGCALC, generating a sign-conflict-free .a static library or Framework.

[0089] In some embodiments, when a new operating system platform (such as macOS, Linux, or QNX) is required, existing preprocessing rules are reused first. macOS reuses iOS preprocessing rules, Linux reuses Android preprocessing rules, and macro definitions are added only when there are differences in preprocessing rules.

[0090] Figure 4 This is a schematic diagram of the structure of a cross-platform compilation device according to some embodiments of this specification.

[0091] like Figure 4 As shown, one or more embodiments of this specification also provide a schematic diagram of a cross-platform compilation device. This cross-platform compilation device may include: The acquisition module 401 is used to acquire the source code file to be compiled. The source code file contains at least one symbol declaration and multiple conditional compilation code blocks. The multiple conditional compilation code blocks are associated with platform macro identifiers corresponding to different preset operating systems, and are used to define preprocessing rules for the symbol declarations to adapt to different preset operating systems. The first determining module 402 is used to determine the target operating system specified for this compilation and the target platform macro identifier corresponding to the target operating system from multiple preset operating systems; The second determining module 403 is used to determine the target conditional compilation code block associated with the target platform macro identifier from multiple conditional compilation code blocks based on the target platform macro identifier. Preprocessing module 404 is used to preprocess symbol declarations based on the preprocessing rules defined by the target conditional compilation code block, so as to obtain a preprocessed source code file corresponding to the target operating system. Compiler module 405 is used to compile and link the preprocessed source code files to generate target code files for the target operating system.

[0092] The acquisition module 401, the first determination module 402, the second determination module 403, the preprocessing module 404, and the compilation module 405 can be used to execute the embodiments corresponding to the cross-platform compilation method described above. For the specific implementation methods of these modules and more details, please refer to the corresponding method section, which will not be elaborated here.

[0093] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0094] Figure 5 This is a schematic diagram of the structure of an electronic device according to some embodiments of this application. For example... Figure 5As shown, the electronic device 500 may include a processor 501 and a memory 502. The electronic device 500 may also include one or more of a multimedia component 503, an input / output (I / O) component 504, and a communication component 505. In this embodiment, the electronic device 500 may be a device that implements the cross-platform compilation method provided in this embodiment.

[0095] The processor 501 controls the overall operation of the electronic device 500 to complete all or part of the steps in the cross-platform compilation method described above. The memory 502 stores various types of data to support the operation of the electronic device 500. This data may include, for example, instructions for any application or method operating on the electronic device 500, and application-related data such as images, audio, video, etc. The memory 502 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 503 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 502 or transmitted via communication component 505. The audio component also includes at least one speaker for outputting audio signals. I / O component 504 provides an interface between processor 501 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 505 is used for wired or wireless communication between the electronic device 500 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, Narrowband Internet of Things (NB-IoT), Enhanced Machine Type Communication (eMTC), or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 505 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0096] In one exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the cross-platform compilation method described above.

[0097] In another exemplary embodiment, a computer-readable storage medium is also provided, having program instructions stored thereon, which, when executed by a processor, implement the steps of the cross-platform compilation method described above. For example, the computer-readable storage medium may be the memory 502 containing the program instructions described above, which may be executed by the processor 501 of the electronic device 500 to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application. Alternatively, when the instructions are executed by a computer, they may be used to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0098] In another exemplary embodiment, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the cross-platform compilation method described above. For example, the computer program product may be the memory 502 containing the computer program described above, and the computer program may be executed by the processor 501 of the electronic device 500 to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application. Alternatively, when the instructions are executed by a computer, they may be used to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0099] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0100] The embodiments, implementation methods, and related technical features of this application can be combined and substituted for each other without conflict.

[0101] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although the descriptions of each embodiment in this application have different focuses, and the parts not described in detail in a certain embodiment can be referred to the relevant embodiments of other embodiments, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of this application without departing from the content of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. A cross-platform compilation method, characterized in that, The method includes: Obtain the source code file to be compiled. The source code file contains at least one symbol declaration and multiple conditional compilation code blocks. The multiple conditional compilation code blocks are associated with platform macro identifiers corresponding to different preset operating systems, and are used to define preprocessing rules for the symbol declarations to adapt to different preset operating systems. From multiple preset operating systems, determine the target operating system specified for this compilation, and the target platform macro identifier corresponding to the target operating system; Based on the target platform macro identifier, determine the target conditional compilation block associated with the target platform macro identifier from multiple conditional compilation blocks; Based on the preprocessing rules defined in the target conditional compilation code block, the symbol declarations are preprocessed to obtain a preprocessed source code file corresponding to the target operating system. The preprocessed source code file is compiled and linked to generate target code files for the target operating system.

2. The method according to claim 1, characterized in that, The preprocessing rules defined based on the target conditional compilation code block are used to preprocess the symbol declarations to obtain a preprocessed source code file corresponding to the target operating system, including: Based on the preprocessing rules defined by the target conditional compilation information, the symbol declarations are preprocessed to change the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, thereby obtaining the preprocessed source code file.

3. The method according to claim 2, characterized in that, The preprocessing rules defined based on the target conditional compilation information are used to preprocess the symbol declarations, thereby changing the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, to obtain the preprocessed source code file, including: When the target operating system is detected to be Android, the symbol declaration is encapsulated in the code block corresponding to the predefined link modifier to change the linking form of the symbol declaration, thereby obtaining the preprocessed source code file. When the target operating system is detected to be a non-Android operating system, the linking format of the symbol declaration is kept as the default linking format to obtain the preprocessed source code file; The predefined linker is used to control the compilation process so that the symbol names corresponding to the symbol declarations within the code block are not changed.

4. The method according to claim 2, characterized in that, The preprocessing rules defined based on the target conditional compilation information are used to preprocess the symbol declarations, thereby changing the namespace, linking form, or export attributes of the symbols corresponding to the symbol declarations in the target code file, to obtain the preprocessed source code file, including: When the target operating system is detected to be iOS, at least some of the symbol declarations are selectively restricted to the scope of the target namespace to obtain the preprocessed source code file; When the target operating system is detected to be a non-iOS operating system, the namespace of the symbol declaration is kept as the global namespace to obtain the preprocessed source code file.

5. The method according to claim 4, characterized in that, The at least part of the symbol declaration includes symbol declarations related to the target vehicle, and the method further includes: Based on the attribute information of the target vehicle and the function type corresponding to at least part of the symbol declaration, the target namespace corresponding to the target vehicle is determined by a preset naming rule; The attribute information includes at least one of vehicle model and manufacturer identifier, and the function type includes at least one of encryption algorithm, compression / decompression algorithm or diagnostic algorithm.

6. The method according to claim 2, characterized in that, The at least one symbol declaration includes a target symbol declaration obtained from an exported macro identifier declaration representing exported attributes. The preprocessing of the symbol declaration based on the preprocessing rules defined by the target conditional compilation information changes the namespace, linking form, or exported attributes of the symbol corresponding to the symbol declaration in the target code file, resulting in the preprocessed source code file, including: When the target operating system is detected to be a Windows operating system, the exported macro identifiers in the target symbol declaration are expanded into predefined exported declaration modifiers to obtain the expanded target symbol declaration; or... When the target operating system is detected to be a non-Windows operating system, the exported macro identifier in the target symbol declaration is expanded to an empty or specified identifier to obtain the expanded target symbol declaration; Based on the expanded target symbol declaration, the preprocessed source code file is obtained; The export declaration modifier is used to instruct that the symbol name corresponding to the target symbol declaration be recorded in the export symbol table of the dynamic link library, so that external programs can access the implementation code corresponding to the symbol name in the export symbol table.

7. The method according to any one of claims 1 to 6, characterized in that, The symbol declaration includes at least one of a function declaration, a variable declaration, or a class declaration.

8. A cross-platform compilation device, characterized in that, The device includes: The acquisition module is used to acquire the source code file to be compiled. The source code file contains at least one symbol declaration and multiple conditional compilation code blocks. The multiple conditional compilation code blocks are associated with platform macro identifiers corresponding to different preset operating systems, and are used to define preprocessing rules for the symbol declarations to adapt to different preset operating systems. The first determining module is used to determine the target operating system specified for this compilation and the target platform macro identifier corresponding to the target operating system from multiple preset operating systems; The second determining module is used to determine the target conditional compilation code block associated with the target platform macro identifier from multiple conditional compilation code blocks based on the target platform macro identifier. The preprocessing module is used to preprocess the symbol declarations based on the preprocessing rules defined in the target conditional compilation code block, so as to obtain a preprocessed source code file corresponding to the target operating system. The compilation module is used to compile and link the preprocessed source code files to generate target code files for the target operating system.

9. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images