Method, system and equipment for adapting freight rate search code to multi-system architecture

Abstract

The invention belongs to the technical field of freight rate search, and provides a method, system and device for adapting freight rate search codes to a multi-system architecture, and the method comprises the steps: compiling a shell script, and obtaining an operation type of a current execution environment and a CPU hardware architecture type by calling the compiled shell; the method comprises the following steps: compiling compatible CMakeLists.txt files for operating systems of different types and different versions, and matching an operating system environment through the compatible CMakeLists.txt files; by storing a plurality of versions of the same shared library and setting names referencing the shared library, the shared libraries of operating systems of different versions are compatible; judging a CPU hardware architecture type through a predefined judgment macro, and accessing a register according to the CPU hardware architecture type; by setting compiling options for compiling marks, the value ranges of character type variables of different CPU hardware architectures are unified. According to the method, the same set of codes can be adapted to different software and hardware architectures, the development efficiency is remarkably improved, the development time is shortened, and the input cost of testing and development personnel is reduced while the function quality is guaranteed.

Description

Technical Field

[0001] The present application belongs to the technical field of freight rate search, and in particular, relates to a method, system and device for adapting a freight rate search code to a multi-system architecture. Background Art

[0002] At present, the freight rate search system relies on the operating system software Red Hat, and the hardware CPU is developed by Intel. The important software and hardware devices that the system relies on are all foreign products. The optimization of the freight rate search system mainly involves two parts: software and hardware. Among them, the target software part refers to the operating system software, using the Kylin operating system; the target hardware part refers to the CPU hardware, using X86 architecture and ARM architecture CPU products.

[0003] The optimization of the freight rate search system is not accomplished overnight, it takes time. During the implementation of the optimization task, the original system is still required to provide stable, reliable, and high-performance freight rate search services. In addition, it is necessary to develop and implement new business requirements proposed by airlines and modify existing problems in the system on the original system. Based on the above considerations, the current optimization process needs to maintain three systems: 1. The existing freight rate search system, which is used to provide real-time freight rate search services and deploy and update new businesses; 2. The optimized freight rate search system based on the X86 architecture and Kylin operating system; 3. The optimized freight rate search system based on the Kylin operating system of the ARM architecture. If the three systems are implemented using three sets of codes, the cost of maintenance and development will increase greatly. At the same time, since the needs of new businesses need to be implemented on three sets of codes respectively, the probability of service errors will also increase.

[0004] The Chinese patent "A software code transplantation method under the trusted innovation environment of a server system" with the publication number CN114756281A discloses a software code transplantation method under the trusted innovation environment of a server system, and the transplantation process uses the docker container technology. By decomposing the functions under the original Windows system, the decomposed code is put back into the container, and restored and deployed on the new optimized platform, cross-platform operation is achieved. However, it is impossible to achieve matching and compatibility between one set of code and multiple systems.

[0005] Therefore, how to use a set of codes to adapt to different operating systems in the process of optimizing the freight rate search system, reduce optimization costs, and reduce the probability of errors in subsequent services has become a technical problem that needs to be solved urgently. Summary of the invention

[0006] In response to the above problems, the present application provides a method, system and device for adapting freight rate search codes to multi-system architectures.

[0007] According to a first aspect of the present application, a method for adapting a freight rate search code to a multi-system architecture is provided, the method comprising: Write a shell script and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shell; Write compatible CMakeLists.txt files for different types and versions of operating systems, and match the operating system environment through compatible CMakeLists.txt files; By saving multiple versions of the same shared library and setting the name of the referenced shared library, it is compatible with shared libraries of different versions of operating systems; Determine the CPU hardware architecture type through predefined judgment macros, and access registers based on the CPU hardware architecture type; By setting compilation options for compilation flags, the value ranges of character type variables for different CPU hardware architectures are unified.

[0008] Preferably, in the method of adapting the freight rate search code to multiple system architectures of the present application, a shell script is written, and the operation type and the CPU hardware architecture type of the current execution environment are respectively obtained by calling the written shell, including: writing two shell scripts respectively, and calling the two written shell scripts respectively by executing the call command in the CMakeLists.txt file of the CMake compilation tool to obtain and save the operating system type of the current execution environment and the CPU hardware architecture type of the current execution environment.

[0009] Preferably, in the method of adapting the freight rate search code to a multi-system architecture of the present application, compatible CMakeLists.txt files are written for operating systems of different types and versions, and the operating system environment is matched through the compatible CMakeLists.txt files, including: in the CMakeLists.txt file, different header file reference paths are set according to different operating system types, and header files in different directories are referenced through the set header file reference paths.

[0010] Preferably, in the method of adapting the freight rate search code to multiple system architectures of the present application, compatible CMakeLists.txt files are written for different types and versions of operating systems, and the operating system environment is matched through the compatible CMakeLists.txt files. It also includes: determining the referenced shared library version according to the version of the operating system by modifying the CMakeLists.txt file.

[0011] Preferably, in the method of adapting the freight rate search code to multiple system architectures of the present application, multiple versions of the same shared library are saved and the names of the referenced shared libraries are set to be compatible with shared libraries of different versions of operating systems, including: saving multiple versions of shared libraries in the operating system directory, distinguishing the versions of the saved shared libraries by setting names, and matching different versions of shared libraries for different versions of operating systems.

[0012] Preferably, in the method for adapting the freight rate search code to multiple system architectures of the present application, in the shared library loading stage, the corresponding shared library version is matched according to the shared library symbol name recorded in the executable file.

[0013] Preferably, in the method for adapting the freight rate search code to multiple system architectures of the present application, the CPU hardware architecture type is determined by a predefined judgment macro, and registers are accessed according to the CPU hardware architecture type, including: predefining a judgment macro in a compiler, determining the CPU hardware architecture type of the current compilation and running environment by the predefined judgment macro, and using different inline assembly to access registers according to the CPU hardware architecture type.

[0014] Preferably, in the method for adapting the freight rate search code to multiple system architectures of the present application, by setting compilation options for compilation flags, the value ranges of character type variables of different CPU hardware architectures are unified, including: in the CMakeLists.txt file, according to the value of the name variable of the CMake compilation tool, the type of the CPU hardware architecture of the current environment is judged, and by adding compilation options to the compilation flags corresponding to the CPU hardware architecture, the type of character type is explicitly limited.

[0015] According to a second aspect of the present application, a system for adapting a freight rate search code to a multi-system architecture is provided. The system for adapting a freight rate search code to a multi-system architecture includes an adaptation server, and the adaptation server includes: The execution environment identification module is used to write shell scripts and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shells; The operating system compatibility module is used to write compatible CMakeLists.txt files for different types and versions of operating systems, and match the operating system environment through compatible CMakeLists.txt files; The shared library compatibility module is used to make shared libraries compatible with different versions of operating systems by saving multiple versions of the same shared library and setting the name of the referenced shared library; CPU hardware architecture compatibility module, used to determine the CPU hardware architecture type through predefined judgment macros and access registers according to the CPU hardware architecture type; The character type unification module is used to unify the value range of character type variables of different CPU hardware architectures by setting compilation options for compilation flags.

[0016] According to a third aspect of the present application, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method of the first aspect of the present application when executing the program.

[0017] The method, system and device for adapting the freight rate search code to multiple system architectures of the present application solve the problem of adapting the same set of codes to different software and hardware architectures; solve the time and labor cost problems caused by developing multiple sets of the same functional codes for different operating system versions and CPU hardware architectures; reduce manual participation in the code compilation and software deployment process, improve work efficiency and system code quality; and can take into account the functional development of existing systems while ensuring the optimization of the freight rate search system. Before the optimized new system is fully put into operation, it is still possible to upgrade and transform new businesses, modify problems and verify functions in the existing environment. These functional codes only need to be implemented once and can be compiled and run on multiple systems, which significantly improves development efficiency and shortens development time. While ensuring functional quality, it reduces the investment costs of testing and developers.

[0018] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures indicated in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 This is an example diagram of the architecture of a system for adapting a freight rate search code to a multi-system architecture according to an embodiment of the present application; Figure 2 This is an example diagram of the architecture of an adaptation server of a system for adapting a fare search code to a multi-system architecture according to an embodiment of the present application; Figure 3 A flowchart of a method for adapting a freight rate search code to a multi-system architecture according to an embodiment of the present application; Figure 4 An example diagram of shared library dependency relationships corresponding to an operating system in the prior art; Figure 5 This is an example diagram of shared library dependencies corresponding to the optimized operating system; Figure 6 An example diagram of a multi-version coexisting shared library implemented according to the method of adapting the freight rate search code to a multi-system architecture of the present application; Figure 7 An example diagram of achieving compatibility between old and new shared library versions according to the method of adapting the freight rate search code to a multi-system architecture of this application; Figure 8 A schematic diagram of the structure of the device provided in this application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0022] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0023] Figure 1 FIG. 1 is an example diagram of the architecture of a system for adapting a fare search code to a multi-system architecture according to an embodiment of the present application, such as Figure 1 As shown, the system may include an adaptation server 101, a communication network 102 and / or one or more adaptation clients 103. Figure 1 The example shown is a plurality of adaptation clients 103 .

[0024] The adaptation server 101 can be any appropriate server for storing information, data, programs and / or any other suitable type of content. In some embodiments, the adaptation server 101 can perform appropriate functions. For example, in some embodiments, the adaptation server 101 can be used for the freight rate search code to adapt to multiple system architectures. As an optional example, in some embodiments, the adaptation server 101 can be used to: write a shell script, and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shell; write compatible CMakeLists.txt files for different types and versions of operating systems, and match the operating system environment through compatible CMakeLists.txt files; by saving multiple versions of the same shared library and setting the name of the referenced shared library, it is compatible with shared libraries of different versions of operating systems; judge the CPU hardware architecture type through a predefined judgment macro, and access registers according to the CPU hardware architecture type; unify the value range of character type variables of different CPU hardware architectures by setting compilation options for compilation flags.

[0025] As another example, in some embodiments, the adaptation server 101 may send the method for adapting the fare search code to the multi-system architecture to the adaptation client 103 for the user to use according to the request of the adaptation client 103 .

[0026] Figure 2 This is an example diagram of the architecture of an adaptation server of a system for adapting a fare search code to a multi-system architecture according to an embodiment of the present application, such as Figure 2 As shown, the adaptation server of this embodiment includes: The execution environment identification module is used to write shell scripts and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shells; The operating system compatibility module is used to write compatible CMakeLists.txt files for different types and versions of operating systems, and match the operating system environment through compatible CMakeLists.txt files; The shared library compatibility module is used to make shared libraries compatible with different versions of operating systems by saving multiple versions of the same shared library and setting the name of the referenced shared library; CPU hardware architecture compatibility module, used to determine the CPU hardware architecture type through predefined judgment macros and access registers according to the CPU hardware architecture type; The character type unification module is used to unify the value range of character type variables of different CPU hardware architectures by setting compilation options for compilation flags.

[0027] As an optional example, in some embodiments, the adaptation client 103 is used to provide a visual adaptation interface, which is used to receive a user's selection input operation for customized sorting of freight fare search results, and to obtain, in response to the selection input operation, an adaptation interface corresponding to the option selected by the selection input operation from the adaptation server 101 and display the adaptation interface, wherein the adaptation interface at least displays information on the freight fare search code adaptation to the multi-system architecture and operation options for the information on the freight fare search code adaptation to the multi-system architecture.

[0028] In some embodiments, the communication network 102 can be any suitable combination of one or more wired and / or wireless networks. For example, the communication network 102 can include any one or more of the following: the Internet, an intranet, a wide area network (WAN), a local area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), and / or any other suitable communication network. The adaptation client 103 can be connected to the communication network 102 via one or more communication links (e.g., communication link 104), and the communication network 102 can be linked to the adaptation server 101 via one or more communication links (e.g., communication link 105). The communication link can be any communication link suitable for transmitting data between the adaptation client 103 and the adaptation server 101, such as a network link, a dial-up link, a wireless link, a hard-wired link, any other suitable communication link, or any suitable combination of such links.

[0029] The adaptation client 103 may include any one or more clients that present an interface related to the fare search code adaptation multi-system architecture in an appropriate form for use and operation by a user. In some embodiments, the adaptation client 103 may include any suitable type of device. For example, in some embodiments, the adaptation client 103 may include a mobile device, a tablet computer, a laptop computer, a desktop computer, and / or any other suitable type of client device.

[0030] Although the adaptation server 101 is illustrated as one device, in some embodiments, any suitable number of devices may be used to perform the functions performed by the adaptation server 101. For example, in some embodiments, multiple devices may be used to implement the functions performed by the adaptation server 101. Alternatively, the functions of the adaptation server 101 may be implemented using a cloud service.

[0031] Based on the above system, an embodiment of the present application provides a method for adapting a fare search code to a multi-system architecture, which is described below through the following embodiments.

[0032] During the optimization process, the main problem that needs to be solved is how to migrate the existing code and the components on which the code depends from the existing compilation and running environment to the optimized environment. In order to support the development and maintenance work under the existing system during the migration process, this embodiment guarantees the optimization quality to the greatest extent and reduces the manpower maintenance cost. Considering both the platform software and hardware, the goal is to adapt the same set of code to multiple optimization system platforms.

[0033] Figure 3 1 is a flowchart of the steps of a method for adapting a fare search code to a multi-system architecture according to an embodiment of the present application. The method for adapting a fare search code to a multi-system architecture of this embodiment can be executed on the adaptation server, such as Figure 3 As shown, the method for adapting the freight rate search code to a multi-system architecture includes the following steps: Step S201: write a shell script, and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shell.

[0034] In the process of optimizing the freight rate search system (DShop), the code and compiler need to be adapted and compatible with different operating system versions (such as redhat or Kylin) and different CPU hardware architectures (X86 or ARM). Therefore, how to obtain the operating system version and CPU type before compiling and executing is a prerequisite.

[0035] Because the existing freight rate search system, the optimized freight rate search system based on the X86 architecture and Kylin operating system, and the optimized freight rate search system based on the Kylin operating system of the ARM architecture have different CPU architectures at the hardware level and operating systems at the software level. Different systems use different versions of the GCC compiler and support inconsistent C++ syntax. This results in a service that compiles and runs normally on a certain platform not getting the correct results on another platform, or even failing to compile successfully. Therefore, in order to meet the requirements of adapting to multiple platforms, it is necessary to make modifications at the source code level first. Make the syntax of the code meet the minimum version requirements supported by GCC on several platform systems. For example, under the Kylin operating system of the X86 architecture, the minimum version of C++ supported by GCC is C++11. Therefore, we must at least ensure that the syntax standard of C++11 is met at the source code level.

[0036] In order to make the code compatible with different CPU hardware architectures and operating systems in the future, this embodiment uses scripts to identify different software and hardware environments. By first identifying different software and hardware environments, compatible adaptation solutions are implemented according to different environments.

[0037] As an optional example, in this embodiment, two shell scripts are written separately, such as A.shell script and B.shell script. A.shell script is used to obtain the operating system type of the current execution environment, and B.shell script obtains the CPU hardware architecture type of the current execution environment. Then, in this embodiment, in the CMakeLists.txt file of the CMake compilation tool, the execute_process command is executed to call the A.shell script and the B.shell script respectively, and the operating system type of the current execution environment is obtained and saved by calling the A.shell script, and the CPU hardware architecture type of the current execution environment is obtained and saved by calling the B.shell script. The execute_process command in this embodiment is a command of the CMake compilation tool, which allows external commands such as system commands and scripts to be executed during the CMake compilation process.

[0038] This embodiment uses CMake compilation tools and scripts to accurately identify the current compilation hardware and software environment, and executes different compilation options according to different CPU hardware architectures and operating system versions.

[0039] Step S202: Compile compatible CMakeLists.txt files for operating systems of different types and versions, and match the operating system environment through the compatible CMakeLists.txt files.

[0040] Different operating systems and CPU hardware architectures have different library paths, compiler characteristics, and system header file locations, such as different default storage paths and compiler default versions. In addition, in practical applications, the range of CMake versions available on each platform is also different. In order to be compatible with different hardware and software environments, this embodiment re-modifies the CMakeLists.txt file based on the acquired hardware and software information, and adapts to different hardware and software environments by writing compatible CMakeLists.txt files and judging by macros in the code.

[0041] During the implementation of the freight rate search system optimization, it is necessary to parse the information in json format through the jsoncpp shared library. However, the default storage path of the json.h header file provided by the jsoncpp shared library is different under different operating systems. For example, under the redhat system, the storage path of the json.h header file is jsoncpp / json / json.h, and under the Kylin system, the storage path of the json.h header file is json.h. In the CMakeLists.txt file of this embodiment, different json.h header file reference paths are set according to different operating system types, and the json.h header files in different directories are referenced by the set json.h header file reference paths. It should be noted that this embodiment can also set reference paths for other header files.

[0042] In actual applications, different operating systems support different minimum versions of shared libraries due to different Linux kernel versions. This embodiment determines the referenced shared library version according to the version of the operating system by modifying the CMakeLists.txt file. For example: During the optimization of the freight rate search system, the shared library libxml++ is required to parse information in XML format. The Kylin system can only use a minimum version 3.0 of the shared library, but the existing environment uses a version 2.6 of the shared library. In order to avoid modifying the interface of the original code to adapt to a higher version of the shared library, this embodiment references different versions of shared libraries for different operating systems. This avoids the introduction of interface modifications and quality risks, and reduces construction time and manpower investment.

[0043] Step S203: by saving multiple versions of the same shared library and setting the name of the referenced shared library, the shared libraries of different versions of operating systems are compatible.

[0044] Save multiple versions of the libicudata shared library in the operating system directory, distinguish the versions of the saved libicudata shared library by setting the file name, and match different versions of the libicudata shared library for different versions of the operating system.

[0045] Under different operating systems, the default versions of some system shared libraries are different. The interfaces provided to the outside in different shared library versions may also be incompatible, and some interface functions may even expire. In order to use the old version of the dynamic link library, it is necessary to link different shared libraries in different operating systems. It should be noted that this embodiment takes the libicudata shared library as an example, and is not limited to compatibility with the libicudata shared library. For example, in the existing system before optimization, the default libicudata shared library is version 38, and the freight rate search system also relies on version 38. However, the default version in the optimized system is 62, which is incompatible with the dependent version 38 interface. In this way, it is necessary to save both versions 38 and 62 of the libicudata shared library in the optimized system. In practical applications, the method of this embodiment is also applicable to compatibility with other shared libraries.

[0046] After migrating to the new platform, the optimized kernel version of the freight rate search system will be upgraded. At the same time, the built-in system shared library will also have a major version update. Figure 4 is an example diagram of shared library dependency relationships corresponding to the operating system in the prior art, such as Figure 4 As shown in the figure, the current code uses the 2.8 version of the xerces-c library, which is linked to the 38 version of the libicudata shared library. The shared library libicudata that xerces-c.so.28 in the code depends on is version 38. The version of the optimized operating system has been upgraded, so the libicudata shared library version that comes with the system has also been updated. Figure 5 This is an example diagram of shared library dependencies corresponding to the optimized operating system, such as Figure 5 As shown in the figure, after the operating system of the optimized environment is upgraded, the version of the libicudata shared library is upgraded to version 62. The 2.8 version of the xerces-c library is not compatible with the 62 version of the libicudata shared library. If the xerces-c library is upgraded at the same time, the new version of xerces-c will be incompatible with the old version of the API. Such modifications are very large, take a long time, and cannot guarantee quality.

[0047] In the shared library loading stage, this embodiment matches the corresponding shared library version according to the shared library symbol name recorded in the executable file. As an optional example, this embodiment saves multiple versions of the libicudata shared library in the operating system directory, distinguishes the versions of the saved libicudata shared library by setting the name, and matches different versions of the libicudata shared library for different versions of the operating system. For example, the freight rate search system service can use a compatible low-version libicudata shared library, and the system in the new environment can use the upgraded high-version libicudata shared library. In this way, the freight rate search service can be adapted to multiple platforms without modifying the original code. Figure 6 This is an example diagram of a multi-version coexisting shared library implemented according to the method of adapting the freight rate search code to multiple system architectures of the present application. Figure 7 This is an example diagram of achieving compatibility between old and new shared library versions according to the method of adapting the freight rate search code to multiple system architectures in this application.

[0048] This embodiment uses the symbolic name naming mechanism of the shared library to find the corresponding shared library version according to the symbolic name recorded in the executable file during the shared library loading phase, thereby solving the problem of not being able to find the lower version system shared library due to the operating system version upgrade.

[0049] Step S204: determine the CPU hardware architecture type through a predefined determination macro, and access registers according to the CPU hardware architecture type.

[0050] Different CPU hardware architectures have different types of registers. Therefore, you need to determine the CPU architecture type in the code first, and use different inline assembly syntax keywords to access different registers according to different types. When optimizing the freight rate search system, in order to record the running time of the business logic, it is necessary to calculate the CPU's main frequency to implement the timing function. This function needs to be implemented through inline assembly language. The current code is based on the assembly language of the X86 architecture to implement the function of calculating the main frequency. This inline assembly uses registers unique to the X86 architecture.

[0051] Different CPU hardware architectures have different internal registers. The freight rate search system source code uses inline assembly, and assembly language is strongly associated with the CPU hardware architecture. The current service operating environment is based on the X86 architecture, so the syntax used and the registers used are all oriented to the X86 architecture. In order to implement the same function on the ARM architecture, it is necessary to modify the code and use the assembly language oriented to the ARM architecture to re-implement some of the same functions.

[0052] This embodiment predefines a judgment macro in the compiler, and uses the predefined judgment macro to judge the CPU hardware architecture type of the current compilation and running environment, and uses different inline assembly access registers according to the CPU hardware architecture type. For example, the inline assembly in the current code uses the EAX and EDX registers unique to X86 and the inline assembly syntax keyword asm of the X86 architecture. This embodiment uses the inline assembly syntax keyword asm unique to the ARM architecture under the ARM hardware architecture, as well as unique registers such as R0-R15, so that the code adapts to multiple systems. In actual applications, this embodiment can predefine the (__aarch64__) macro for the CPU hardware architecture type through the C++ language compiler.

[0053] This embodiment generates different implementations for the same function through inline assembly for different CPU hardware architectures, and calls different inline assembly functions according to different macro compilation options during the compilation process. It should be noted that in actual applications, this embodiment can also use different inline assembly to calculate the CPU main frequency according to different CPU hardware architectures.

[0054] Step S205: unifying the value ranges of character type variables of different CPU hardware architectures by setting compilation options for compilation flags.

[0055] In different CPU hardware architectures and compiler environments, the default value range of the character type (char) is different, and different values ​​will affect the correctness of the business logic judgment and the accuracy of the final calculation result. In C and C++ programming languages, the char type is a relatively special data type in the standard. In essence, the size of the char type is 1 byte (8 bits), but its sign attribute, whether it is signed or unsigned, is not strictly specified in the standard, which leads to differences in different hardware architectures and compiler implementations. For example, the default value range of the character type (char) in the two CPU hardware architecture environments of X86 and ARM is different. The char type is a signed char attribute under the X86 architecture, with a value range of -128-127, and an unsigned char attribute under the ARM architecture, with a value range of 0-255. This results in different results for the judgment and value of char in the code under different CPU hardware architectures. In order to ensure the uniformity of the code, this embodiment needs to identify and unify the value ranges of these character type variables.

[0056] In the CMakeLists.txt file, according to the value of the name variable of the CMake compiler tool, the type of the CPU hardware architecture of the current environment is judged, and the type of the character type is explicitly limited by adding a compile option to the compile flag corresponding to the CPU hardware architecture. As an optional example, in the present embodiment, according to the value of CMAKE_HOST_SYSTEM_PROCESSOR, the type of the CPU hardware architecture of the current environment is judged. If the type of the CPU hardware architecture of the current environment is an ARM architecture, the type of the character type is explicitly limited by adding the -fsigned-char compile option to the two compile flags CMAKE_C_FLAGS and CMAKE_CXX_FLAGS, so that the value range of the character type is consistent under different CPU hardware architectures, and the compiler is clearly informed to treat the char type as a signed type. This ensures that the business logic executed by the same input is the same under different CPU architecture environments, and the same operation result is determined.

[0057] In view of the different value ranges of character types under different CPU hardware architectures, this embodiment uses the CMake compilation tool to unify the value ranges of character types in CMakeLists.txt.

[0058] The optimization of the freight rate search system requires a gradual process. After the optimization task begins, the original environment still needs to be developed and maintained.

[0059] The method and system for adapting the freight rate search code to multiple system architectures of this embodiment solves the problem of adapting the same set of codes to different software and hardware architectures; solves the time and labor cost problems caused by developing multiple sets of the same function code for different operating system versions and CPU hardware architectures; reduces manual participation in the code compilation and software deployment process, and improves work efficiency and system code quality.

[0060] The method and system for adapting the freight rate search code to the multi-system architecture of this embodiment can ensure the optimization of the freight rate search system while taking into account the functional development of the existing system. Before the optimized new system is fully put into operation, the new business can still be upgraded, the problem can be corrected, and the function can be verified in the existing environment. These function codes only need to be implemented once and can be compiled and run in multiple systems, which significantly improves development efficiency, shortens development time, and reduces the investment cost of testing and developers while ensuring functional quality.

[0061] like Figure 8As shown, the present application also provides a device, including a processor 310, a communication interface 320, a memory 330 for storing a computer program executable by the processor, and a communication bus 340. The processor 310, the communication interface 320, and the memory 330 communicate with each other through the communication bus 340. The processor 310 implements the above-mentioned method of adapting the freight rate search code to a multi-system architecture by running an executable computer program.

[0062] Among them, the computer program in the memory 330 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0063] The system embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected based on actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art may understand and implement it without creative effort.

[0064] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, or of course by hardware. Based on such an understanding, the above technical solution can essentially or in other words be embodied in the form of a software product that contributes to the prior art. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of each embodiment or some parts of the embodiment.

[0065] Although the present application has been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that it is still possible to modify the technical solutions described in the aforementioned embodiments, or to make equivalent replacements for some of the technical features therein; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for adapting a freight rate search code to a multi-system architecture, characterized in that: The method comprises: Write a shell script and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shell; Write compatible CMakeLists.txt files for different types and versions of operating systems, and match the operating system environment through compatible CMakeLists.txt files; By saving multiple versions of the same shared library and setting the name of the referenced shared library, it is compatible with shared libraries of different versions of operating systems; Determine the CPU hardware architecture type through predefined judgment macros, and access registers based on the CPU hardware architecture type; By setting compilation options for compilation flags, the value ranges of character type variables for different CPU hardware architectures are unified.

2. The method for adapting the freight rate search code to a multi-system architecture according to claim 1, characterized in that: Write a shell script, and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shell, including: write two shell scripts respectively, and execute the call command in the CMakeLists.txt file of the CMake compilation tool to call the two shell scripts respectively to obtain and save the operating system type and the CPU hardware architecture type of the current execution environment.

3. The method for adapting the freight rate search code to a multi-system architecture according to claim 1, characterized in that: Compatible CMakeLists.txt files are written for different types and versions of operating systems, and the operating system environment is matched through the compatible CMakeLists.txt files, including: in the CMakeLists.txt file, different header file reference paths are set according to different operating system types, and header files in different directories are referenced through the set header file reference paths.

4. The method for adapting the freight rate search code to a multi-system architecture according to claim 1, characterized in that: Compatible CMakeLists.txt files are written for different types and versions of operating systems, and the operating system environment is matched through the compatible CMakeLists.txt files. The steps also include: determining the referenced shared library version according to the operating system version by modifying the CMakeLists.txt file.

5. The method for adapting the freight rate search code to a multi-system architecture according to claim 1, characterized in that: By saving multiple versions of the same shared library and setting the name of the referenced shared library, it is compatible with shared libraries of different versions of operating systems, including: saving multiple versions of shared libraries in the operating system directory, distinguishing the versions of the saved shared libraries by setting the names, and matching different versions of shared libraries for different versions of operating systems.

6. The method for adapting the freight rate search code to a multi-system architecture according to claim 1, characterized in that: During the shared library loading phase, the corresponding shared library version is matched according to the shared library symbol name recorded in the executable file.

7. The method for adapting the freight rate search code to a multi-system architecture according to claim 1, characterized in that: The CPU hardware architecture type is determined by using a predefined determination macro, and registers are accessed according to the CPU hardware architecture type, including: predefining determination macros in a compiler, determining the CPU hardware architecture type of a current compilation and running environment by using the predefined determination macros, and using different inline assemblies to access registers according to the CPU hardware architecture type.

8. The method for adapting the freight rate search code to a multi-system architecture according to claim 1, characterized in that: By setting compilation options for compilation flags, the value ranges of character type variables for different CPU hardware architectures are unified, including: in the CMakeLists.txt file, the type of the CPU hardware architecture of the current environment is judged according to the value of the name variable of the CMake compilation tool, and the type of the character type is explicitly limited by adding compilation options to the compilation flags corresponding to the CPU hardware architecture.

9. A system for adapting freight rate search codes to a multi-system architecture, characterized in that: The system for adapting the freight rate search code to the multi-system architecture includes an adaptation server, and the adaptation server includes: The execution environment identification module is used to write shell scripts and obtain the operation type and CPU hardware architecture type of the current execution environment by calling the written shells; The operating system compatibility module is used to write compatible CMakeLists.txt files for different types and versions of operating systems, and match the operating system environment through compatible CMakeLists.txt files; The shared library compatibility module is used to make shared libraries compatible with different versions of operating systems by saving multiple versions of the same shared library and setting the name of the referenced shared library; CPU hardware architecture compatibility module, used to determine the CPU hardware architecture type through predefined judgment macros and access registers according to the CPU hardware architecture type; The character type unification module is used to unify the value range of character type variables of different CPU hardware architectures by setting compilation options for compilation flags.

10. A computer device, characterized in that: The computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the method according to any one of claims 1 to 8 when executing the program.

Images