Non-intrusive software development methods, devices, terminals, and storage media

Abstract

This invention provides a non-intrusive software development method, apparatus, terminal, and storage medium. Both the platform directory and the product directory are independent directories; the platform directory includes a platform compiled directory, and the product directory includes a product compiled directory. The method includes: when a product needs to use a platform dynamic library file, obtaining the path between the platform compiled directory and the product compiled directory through the compiled executable file; and obtaining the required platform dynamic library file based on the path between the platform compiled directory and the product compiled directory. This invention achieves non-intrusive software development by separating the platform directory and the product directory, making each an independent directory. This solves the problem of confusion caused by intrusive directory structures and also addresses the issue of products needing to use platform dynamic libraries under a non-intrusive directory structure.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a non-intrusive software development method, apparatus, terminal, and storage medium. Background Technology

[0002] In software development, scenarios involving secondary development based on existing programs are frequent. In companies with multiple business directions, some basic, general-purpose software modules are typically shared across products from various business directions; these shared software modules are called "platforms." Software modules developed on top of these platforms for specific business needs are called "products."

[0003] In traditional management, platforms and products often adopt a "hybrid" approach, both in terms of source code and deployment. For example, products are developed directly within the platform's directory (mixed source code directories), and the compiled program files, resources, configuration files, etc., also directly use the platform's directory structure (mixed deployment directories). This hybrid approach is called "intrusive." While this method requires less initial investment, the boundaries are unclear; a file cannot be easily identified as belonging to the platform or the product, leading to confusion. For example, it's difficult to identify platform and product versions; it's difficult to verify the completeness of platform and product files; when replacing platform or product versions, it's difficult to confirm correctness, and old files from the previous version may remain; once platforms and products are mixed, it's difficult to separate them; platform or product files are easily committed to each other's SVN, causing problems during re-integration and release; platform filenames and product filenames may conflict; and so on. Summary of the Invention

[0004] This invention provides a non-intrusive software development method, apparatus, terminal, and storage medium to solve the problem of confusion caused by the mixing of existing technology platform catalogs and product catalogs.

[0005] In a first aspect, embodiments of the present invention provide a non-intrusive software development method, wherein the platform directory and the product directory are both independent directories; the platform directory includes a platform compilation generation directory, and the product directory includes a product compilation generation directory; the non-intrusive software development method includes:

[0006] When a product needs to use the platform's dynamic library files, the path between the platform's compiled directory and the product's compiled directory is obtained through the compiled executable file;

[0007] Based on the path of the platform's compiled directory relative to the product's compiled directory, obtain the required platform's dynamic library files.

[0008] In one possible implementation, the path between the platform's compiled output directory and the product's compiled output directory is obtained through the compiled executable file, including:

[0009] If the current operating system is Windows, the manifest file created by the platform compilation directory is obtained through the compiled executable file, and the path of the platform compilation directory relative to the product compilation directory is obtained based on the manifest file;

[0010] If the current operating system is Linux or Unix, the path of the platform's compiled output directory relative to the product's compiled output directory can be obtained through the rpath marker of the compiled executable file.

[0011] In one possible implementation, non-intrusive software development methods also include:

[0012] The first interface function provided by the platform for obtaining file paths implements the logic of overwriting the platform target file with the product target file when a product target file exists in the product directory. Specifically, the first interface function returns the absolute path of the product target file when it exists in the product directory, and otherwise returns the absolute path of the platform target file. The path of the product target file relative to the product root directory is the same as the path of the platform target file relative to the platform root directory, and the filenames of the product target file and the platform target file are the same.

[0013] In one possible implementation, non-intrusive software development methods also include:

[0014] The platform provides a second interface function to obtain the plugin path. When a product target plugin exists in the product directory, the product target plugin logic overrides the platform target plugin. The second interface function returns the absolute path of the product target plugin if it exists in the product directory, and otherwise returns the absolute path of the platform target plugin. The path of the product target plugin relative to the product root directory is the same as the path of the platform target plugin relative to the platform root directory, and the plugin names of the product target plugin and the platform target plugin are the same.

[0015] In one possible implementation, the platform directory includes a platform header file directory; non-intrusive software development methods also include:

[0016] By adding the path to the platform header file directory to the parameters passed to the compiler, the product can use the platform's header files through the path to the platform header file directory.

[0017] In one possible implementation, non-intrusive software development methods also include:

[0018] By adding the path to the platform's compiled output directory to the parameters passed to the compiler, the product can use the platform's library files by following the path of the platform's compiled output directory.

[0019] Secondly, embodiments of the present invention provide a non-intrusive software development apparatus, wherein the platform directory and the product directory are both independent directories; the platform directory includes a platform compilation generation directory, and the product directory includes a product compilation generation directory; the non-intrusive software development apparatus includes:

[0020] The path acquisition module is used to obtain the path between the platform's compiled directory and the product's compiled directory when the product needs to use the platform's dynamic library files.

[0021] The dynamic library acquisition module is used to obtain the required dynamic library files for the platform based on the path of the platform's compiled directory relative to the product's compiled directory.

[0022] In one possible implementation, the path acquisition module is specifically used for:

[0023] When a product needs to use the platform's dynamic library files, if the current operating system is Windows, the manifest file created by the platform's compilation directory is obtained through the compiled executable file, and the path of the platform's compilation directory relative to the product's compilation directory is obtained based on the manifest file.

[0024] When a product needs to use the platform's dynamic library files, if the current operating system is Linux or Unix, the path between the platform's compiled directory and the product's compiled directory can be obtained through the rpath marker of the compiled executable file.

[0025] Thirdly, embodiments of the present invention provide a terminal, including a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the non-intrusive software development method as described in the first aspect or any possible implementation thereof.

[0026] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the non-intrusive software development method as described in the first aspect or any possible implementation thereof.

[0027] This invention provides a non-intrusive software development method, apparatus, terminal, and storage medium. By separating the platform directory and product directory, each becoming an independent directory, non-intrusive software development is achieved, thereby solving the problem of confusion caused by intrusive methods. Furthermore, when the product needs to use the platform's dynamic library files, the path between the platform's compiled directory and the product's compiled directory is obtained through the compiled executable file. Based on this path, the required platform dynamic library files are obtained, thus solving the problem of the product needing to use the platform's dynamic libraries. Attached Figure Description

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

[0029] Figure 1 This is a flowchart illustrating the non-intrusive software development method provided in this embodiment of the invention.

[0030] Figure 2 This is a schematic diagram of the non-intrusive directory structure in the development state provided by an embodiment of the present invention;

[0031] Figure 3 This is a schematic diagram of the non-intrusive directory structure in the deployment state provided by an embodiment of the present invention;

[0032] Figure 4 This is a schematic diagram of the software development process provided in an embodiment of the present invention;

[0033] Figure 5 This is a schematic diagram of the structure of the non-intrusive software development device provided in an embodiment of the present invention;

[0034] Figure 6 This is a schematic diagram of the terminal provided in an embodiment of the present invention. Detailed Implementation

[0035] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the invention. However, those skilled in the art will understand that the invention can be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of the invention with unnecessary detail.

[0036] To make the objectives, technical solutions, and advantages of the present invention clearer, specific embodiments will be described below in conjunction with the accompanying drawings.

[0037] Based on the background technology, intrusive directory structures are prone to confusion. For example, it's difficult to identify platform and product versions; it's hard to verify the completeness of platform and product files; when replacing platform or product versions, it's difficult to confirm correctness and may leave behind legacy files from the previous version; once platforms and products are mixed, it's difficult to separate them again; platform or product files are easily committed to each other's SVN, leading to inconsistencies and problems during re-integration and release; platform and product filenames may conflict; and so on. Therefore, this application proposes a non-intrusive directory structure where the platform and product directories are independent, and based on this, a non-intrusive software development method is proposed.

[0038] See Figure 1 The diagram illustrates the implementation flowchart of the non-intrusive software development method provided in this embodiment of the invention. The executing entity of the non-intrusive software development method can be a terminal.

[0039] In this embodiment, the platform directory and the product directory are independent directories; the platform directory includes a platform compilation and generation directory, and the product directory includes a product compilation and generation directory. The platform compilation and generation directory may include files compiled by the platform, and the product compilation and generation directory may include files compiled by the product.

[0040] Figure 2 The development status directory structure is shown. Figure 3 The deployment directory structure is shown. The development directory structure refers to the directory structure within a code repository (such as an SVN or Git repository), where developers can directly develop, run, and test after pulling the code repository content. The deployment directory structure refers to the directory structure after the product is installed on the user's machine. Compared to the development directory structure, the deployment directory structure omits the header file directory and the source code directory.

[0041] See Figure 2 In development mode, the platform directory may include at least one of the following directories: platform configuration directory, platform resource directory, platform header file directory, platform code directory, platform compiled directory, and platform log directory. Similarly, in development mode, the product directory may include at least one of the following directories: product configuration directory, product resource directory, product header file directory, product code directory, product compiled directory, and product log directory.

[0042] See Figure 3In deployment mode, the platform directory may include at least one of the following directories: platform configuration directory, platform resource directory, platform compilation and generation directory, and platform log directory. Similarly, in deployment mode, the product directory may include at least one of the following directories: product configuration directory, product resource directory, product compilation and generation directory, and product log directory.

[0043] It should be noted that, Figure 2 and Figure 3 This is merely an example of a directory structure under different states; in actual use, the directory structure may include more or fewer directories. The contents of a directory with the same name can be identical in development and deployment states.

[0044] See Figure 1 The aforementioned non-intrusive software development methods may include:

[0045] In S101, when a product needs to use the platform's dynamic library files, the path between the platform's compiled directory and the product's compiled directory is obtained through the compiled executable file.

[0046] Non-intrusive directory structures have the problem of finding dynamic libraries at runtime, that is, searching for dependent databases when the process starts, which is an operating system behavior.

[0047] The product code will use the interfaces provided by the platform module. If the platform library used is a dynamic library, it is also necessary to be able to successfully find the dynamic library file at runtime.

[0048] In this embodiment, when the product needs to use the platform's dynamic library files, the operating system can obtain the path between the platform's compiled directory and the product's compiled directory through the compiled executable file during program execution. This embodiment does not impose specific limitations on the implementation method for obtaining the path between the platform's compiled directory and the product's compiled directory through the compiled executable file.

[0049] In S102, the required platform dynamic library files are obtained based on the path of the platform compilation directory relative to the product compilation directory.

[0050] After obtaining the path of the platform compilation directory relative to the product compilation directory, the operating system can obtain the required platform dynamic library files based on that path.

[0051] This embodiment separates the platform directory and the product directory, making each an independent directory. Based on this, non-intrusive software development is achieved, thereby solving the problem of confusion caused by intrusive methods. In addition, when the product needs to use the platform's dynamic library files, the path of the platform's compiled directory relative to the product's compiled directory is obtained through the compiled executable file. Based on the path of the platform's compiled directory relative to the product's compiled directory, the required platform dynamic library files are obtained, thus solving the problem of the product needing to use the platform's dynamic libraries.

[0052] In some embodiments, obtaining the path between the platform compilation directory and the product compilation directory through the compiled executable file in S101 above may include:

[0053] If the current operating system is Windows, the manifest file created by the platform compilation directory is obtained through the compiled executable file, and the path of the platform compilation directory relative to the product compilation directory is obtained based on the manifest file;

[0054] If the current operating system is Linux or Unix, the path of the platform's compiled output directory relative to the product's compiled output directory can be obtained through the rpath marker of the compiled executable file.

[0055] In this embodiment, different operating systems use different methods to obtain the path of the platform compilation directory relative to the product compilation directory.

[0056] In Windows systems, the path between the platform's build directory and the product's build directory is obtained through a manifest file. A manifest file can be created in the platform's build directory; the filename can be "platform build directory name.manifest", and its content can be as follows:

[0057] <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

[0058] <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestversion="1.0">

[0059] <assemblyidentity name="平台编译生成目录相对产品编译生成目录的路径" processorArchitecture="amd64" version="1.0.0.0" type="win32" / >

[0060] <file name="xxx.dll" / >

[0061] List all dynamic libraries in this directory…

[0062] <file name="xxx.dll" / >

[0063] < / assembly>

[0064] During compilation, parameters are passed to the linker, and the information from the manifest file is generated into the compiled executable file. When the program runs, the operating system can find the manifest file through the compiled executable file. The manifest file contains the path of the platform's compiled directory relative to the product's compiled directory. Therefore, the path of the platform's compiled directory relative to the product's compiled directory can be obtained through the manifest file, and the required dynamic library can be found based on this path.

[0065] In a QT project, the manifest file can be set up in the following ways:

[0066] QMAKE_LFLAGS += " / MANIFESTDEPENDENCY:type='win32' name='Path to platform compilation directory relative to product compilation directory' version='1.0.0.0' language='*'processorArchitecture='*'"

[0067] QMAKE_LFLAGS += \" / MANIFEST:embed\"

[0068] It should be noted that the name here must be consistent with the name in the manifest file.

[0069] In Linux or Unix systems, the rpath tag mechanism in ELF files can be used to solve the problem of finding dynamic libraries at runtime. This mechanism is provided by the ELF file identifier.

[0070] During compilation, parameters are passed to the linker, specifying the path between the platform's compiled directory and the product's compiled directory in the `rpath` tag of the compiled file. At runtime, the operating system uses this path to locate the required dynamic libraries.

[0071] QMAKE_RPATHDIR += Path of the platform build directory relative to the product build directory

[0072] In some embodiments, the above-described non-intrusive software development method may further include:

[0073] The first interface function provided by the platform for obtaining file paths implements the logic of overwriting the platform target file with the product target file when a product target file exists in the product directory. Specifically, the first interface function returns the absolute path of the product target file when it exists in the product directory, and otherwise returns the absolute path of the platform target file. The path of the product target file relative to the product root directory is the same as the path of the platform target file relative to the platform root directory, and the filenames of the product target file and the platform target file are the same.

[0074] Using product target file logic to override platform target file means using product target file to override platform target file in code logic, so that when product target file exists, the product target file can be used first, instead of replacing the platform target file in the platform directory with the product target file in the product directory.

[0075] Non-intrusive directory structures still present the challenge of locating resource files and configuration files at runtime. Resource files can reside in their respective resource directories, while configuration files can be located in their respective configuration directories. The target files mentioned above can be target resource files and / or target configuration files.

[0076] Platforms and products each have their own resource files (such as images, translations, etc.) and configuration files (such as program runtime configurations, etc.).

[0077] In software development, the following situation exists: a software module belongs to a platform, and its default resources and configuration files (such as images, styles, and translations on the interface) exist in the platform directory. However, these are not suitable for a particular product, and the product needs to modify them. Directly replacing files in the platform directory would be a return to the old "intrusive" approach, with many drawbacks mentioned in the background.

[0078] The "non-intrusive" solution is to prioritize using target files with the same path and filename in the product directory. In other words, files in the product directory logically override identical files in the platform directory. The approach is as follows:

[0079] Deploy the necessary files for the product in the product directory, ensuring the paths and filenames are consistent with those in the platform directory; leave the relevant files in the platform directory unchanged.

[0080] The platform code provides a unified interface for retrieving resource files and configuration files, known as the first interface. All code within the platform and products uses this first interface to obtain resources and configuration files. The function corresponding to the first interface, i.e., the first interface function, takes a relative path of the target file relative to the platform's root directory as input and returns the absolute path of the target file.

[0081] The internal logic of the first interface function is as follows: if a product target file exists in the product directory, it returns the absolute path of the product target file in the product directory; otherwise, it returns the absolute path of the platform target file in the platform directory. If neither a product target file nor a platform target file exists in the platform directory, it returns failure.

[0082] This embodiment uses interface encapsulation to prioritize the use of target files in the product directory, enabling the product to logically overwrite the platform's files without modifying the platform's files.

[0083] In some embodiments, the above-described non-intrusive software development method may further include:

[0084] The platform provides a second interface function to obtain the plugin path. When a product target plugin exists in the product directory, the product target plugin logic overrides the platform target plugin. The second interface function returns the absolute path of the product target plugin if it exists in the product directory, and otherwise returns the absolute path of the platform target plugin. The path of the product target plugin relative to the product root directory is the same as the path of the platform target plugin relative to the platform root directory, and the plugin names of the product target plugin and the platform target plugin are the same.

[0085] Using product target plugin logic to override platform target plugin means using product target plugin logic to override platform target plugin in code logic, so that when product target plugin exists, product target plugin can be used first, instead of replacing platform target plugin in platform directory with product target plugin in product directory.

[0086] The non-intrusive directory structure also presents the issue of loading product plugin libraries onto the platform. Similar to solving the problem of finding resource files and configuration files at runtime, an interface for obtaining plugins is encapsulated, namely the second interface. The corresponding function is the second interface function, which prioritizes using the plugin dynamic library under the product directory, so that the product can logically override the platform's plugins without modifying the platform's plugins.

[0087] In some embodiments, the platform directory includes a platform header file directory; the non-intrusive software development method further includes:

[0088] By adding the path to the platform header file directory to the parameters passed to the compiler, the product can use the platform's header files through the path to the platform header file directory.

[0089] The non-intrusive directory structure still has the issue of finding header files during compilation. Product code uses interfaces provided by platform modules, therefore requiring header files for those platform interfaces.

[0090] This can be resolved by setting the header file directory for the compiler. Add the path to the platform header file directory to the parameters passed to the compiler. This path can be an absolute path or a relative path. The relative path can be the path of the platform header file directory relative to the corresponding project file; for example, in a Qt project, it could be the corresponding Qt project file. In a Qt project, this can be set in the following way:

[0091] INCLUDEPATH += the relative path to the platform header file directory

[0092] In some embodiments, the non-intrusive software development method further includes:

[0093] By adding the path to the platform's compiled output directory to the parameters passed to the compiler, the product can use the platform's library files by following the path of the platform's compiled output directory.

[0094] Non-intrusive directory structures still have the problem of finding libraries during compilation. Product code uses interfaces provided by platform modules, so during compilation, the linker needs to be able to find the library files generated by the platform (such as .so and .a extensions under Linux, and .dll and .lib files under Windows).

[0095] This can be resolved by setting the library search directory for the linker. Add the path to the platform's compiled directory to the parameters passed to the compiler. This path can be an absolute path or a relative path. The relative path can be the path of the compiled directory relative to the corresponding project file; for example, in a Qt project, it could be the corresponding Qt project file. In a Qt project, this can be set in the following way:

[0096] #The connector finds the path to the directly linked library.

[0097] LIBS += -L is the relative path to the directory generated by the platform compilation.

[0098] #The connector finds the paths of implicit dependencies (libraries linked by directly linked libraries).

[0099] QMAKE_RPATHLINKDIR += The relative path to the directory generated by the platform compilation.

[0100] Figure 4 It illustrates the relevant processes of software development, specifically the processes during compilation and runtime, as well as the related problems encountered.

[0101] This embodiment proposes a directory structure where the platform and product are independent directories in both source code (development) and deployment states, clearly separated. This approach is called "non-intrusive." The non-intrusive directory structure solves many of the problems associated with intrusive directory structures. For example, with independent code directories, the platform team and product team are each responsible for their own, facilitating management, such as code permission control. When upgrading the platform or product separately, the files are not mixed, making the process very clear and less prone to problems. For instance, if a product modifies a file on the platform, the platform upgrade might overwrite the product's changes. The platform and product do not modify or replace files, ensuring clear responsibilities and facilitating problem analysis and localization. It also facilitates verification of deployment correctness, as each platform and product only needs to verify its own file list.

[0102] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0103] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.

[0104] Figure 5 A schematic diagram of the structure of the non-intrusive software development apparatus provided in an embodiment of the present invention is shown. For ease of explanation, only the parts related to the embodiment of the present invention are shown, and are described in detail below:

[0105] The platform directory and product directory are separate directories; the platform directory includes the platform compilation and generation directory, and the product directory includes the product compilation and generation directory; for example... Figure 5 As shown, the non-intrusive software development device 30 may include a path acquisition module 31 and a dynamic library acquisition module 32.

[0106] The path acquisition module 31 is used to obtain the path of the platform's compiled directory relative to the product's compiled directory through the compiled executable file when the product needs to use the platform's dynamic library files.

[0107] The dynamic library acquisition module 32 is used to obtain the required platform dynamic library files based on the path of the platform compilation directory relative to the product compilation directory.

[0108] In one possible implementation, the path acquisition module 31 is specifically used for:

[0109] When a product needs to use the platform's dynamic library files, if the current operating system is Windows, the manifest file created by the platform's compilation directory is obtained through the compiled executable file, and the path of the platform's compilation directory relative to the product's compilation directory is obtained based on the manifest file.

[0110] When a product needs to use the platform's dynamic library files, if the current operating system is Linux or Unix, the path between the platform's compiled directory and the product's compiled directory can be obtained through the rpath marker of the compiled executable file.

[0111] In one possible implementation, the non-intrusive software development apparatus 30 may further include: a target file logical overlay module.

[0112] The target file logic overriding module is used to obtain the file path through the first interface function provided by the platform. When a product target file exists in the product directory, the platform target file logic overwrites the platform target file. The first interface function returns the absolute path of the product target file if it exists in the product directory, and otherwise returns the absolute path of the platform target file. The path of the product target file relative to the product root directory is the same as the path of the platform target file relative to the platform root directory, and the filenames of the product target file and the platform target file are the same.

[0113] In one possible implementation, the non-intrusive software development apparatus 30 may further include: a target plug-in logic overlay module.

[0114] The target plugin logic override module is used to override the platform target plugin when a product target plugin exists in the product directory, by using the second interface function provided by the platform to obtain the plugin path. Specifically, the second interface function returns the absolute path of the product target plugin if it exists in the product directory, and otherwise returns the absolute path of the platform target plugin. The path of the product target plugin relative to the product root directory is the same as the path of the platform target plugin relative to the platform root directory, and the plugin names of the product target plugin and the platform target plugin are the same.

[0115] In one possible implementation, the platform directory includes a platform header file directory; the non-intrusive software development apparatus 30 may also include a header file acquisition module.

[0116] The header file retrieval module enables the product to use the platform's header files by adding the path to the platform's header file directory to the parameters passed to the compiler.

[0117] In one possible implementation, the non-intrusive software development apparatus 30 may further include a library file acquisition module.

[0118] The library file retrieval module is used to enable the product to use the platform's library files by adding the path of the platform's compilation directory to the parameters passed to the compiler.

[0119] Figure 6 This is a schematic diagram of a terminal provided in an embodiment of the present invention. Figure 6 As shown, the terminal 4 in this embodiment includes a processor 40 and a memory 41. The memory 41 stores a computer program 42, and the processor 40 calls and runs the computer program 42 stored in the memory 41 to perform the steps described in the various embodiments of the non-intrusive software development methods, for example... Figure 1S101 to S102 are shown. Alternatively, the processor 40 is used to call and run the computer program 42 stored in the memory 41 to implement the functions of each module / unit in the above-described device embodiments, for example... Figure 5 The functions of modules / units 31 to 32 shown.

[0120] For example, the computer program 42 can be divided into one or more modules / units, which are stored in the memory 41 and executed by the processor 40 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program 42 in the terminal 4. For example, the computer program 42 can be divided into... Figure 5 Modules / units 31 to 32 are shown.

[0121] The terminal 4 may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that... Figure 6 This is merely an example of terminal 4 and does not constitute a limitation on terminal 4. It may include more or fewer components than shown, or combine certain components, or different components. For example, the terminal may also include input / output devices, network access devices, buses, etc.

[0122] The processor 40 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0123] The memory 41 can be an internal storage unit of the terminal 4, such as a hard disk or memory of the terminal 4. The memory 41 can also be an external storage device of the terminal 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the terminal 4. Furthermore, the memory 41 can include both internal storage units and external storage devices of the terminal 4. The memory 41 is used to store the computer program and other programs and data required by the terminal. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0124] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0125] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0126] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0127] In the embodiments provided by this invention, it should be understood that the disclosed devices / terminals and methods can be implemented in other ways. For example, the device / terminal embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0130] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various non-intrusive software development method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in the computer-readable medium may be appropriately added to or subtracted from the content as required by the legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium may not include electrical carrier signals and telecommunication signals.

[0131] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions 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 invention, and should all be included within the protection scope of the present invention.

Claims

1. A non-intrusive software development method, characterized in that, A non-intrusive directory structure is used; the platform directory and the product directory are independent directories; the platform directory includes the platform compilation and generation directory, and the product directory includes the product compilation and generation directory. The non-intrusive software development method includes: When a product needs to use the platform's dynamic library files, the path between the platform's compiled directory and the product's compiled directory is obtained through the compiled executable file; Based on the path of the platform's compiled directory relative to the product's compiled directory, obtain the required platform dynamic library files; The step of obtaining the path between the platform's compiled directory and the product's compiled directory through the compiled executable file includes: If the current operating system is Windows, then the manifest file created by the platform compilation directory is obtained through the compiled executable file, and the path of the platform compilation directory relative to the product compilation directory is obtained based on the manifest file; If the current operating system is Linux or Unix, the path of the platform's compiled output directory relative to the product's compiled output directory can be obtained by using the rpath tag of the compiled executable file.

2. The non-intrusive software development method according to claim 1, characterized in that, The non-intrusive software development method also includes: The platform provides a first interface function to obtain the file path. When a product target file exists in the product directory, the platform target file is logically overwritten by the product target file. Specifically, the first interface function returns the absolute path of the product target file if it exists in the product directory, and otherwise returns the absolute path of the platform target file. The path of the product target file relative to the product root directory is the same as the path of the platform target file relative to the platform root directory, and the filenames of the product target file and the platform target file are identical.

3. The non-intrusive software development method according to claim 1, characterized in that, The non-intrusive software development method also includes: The platform provides a second interface function to obtain the plugin path. When a target product plugin exists in the product directory, the target product plugin logic is used to override the platform target plugin. Specifically, the second interface function returns the absolute path of the target product plugin if it exists in the product directory, and otherwise returns the absolute path of the platform target plugin. The path of the target product plugin relative to the product root directory is the same as the path of the platform target plugin relative to the platform root directory, and the plugin names of the target product plugin and the platform target plugin are the same.

4. The non-intrusive software development method according to claim 1, characterized in that, The platform directory includes the platform header file directory; The non-intrusive software development method also includes: By adding the path to the platform header file directory to the parameters passed to the compiler, the product can use the platform's header files through the path to the platform header file directory.

5. The non-intrusive software development method according to any one of claims 1 to 4, characterized in that, The non-intrusive software development method also includes: By adding the path to the platform's compilation output directory to the parameters passed to the compiler, the product can use the platform's library files by following the path of the platform's compilation output directory.

6. A non-intrusive software development device, characterized in that, A non-intrusive directory structure is used; the platform directory and the product directory are independent directories; the platform directory includes the platform compilation and generation directory, and the product directory includes the product compilation and generation directory. The non-intrusive software development device includes: The path acquisition module is used to obtain the path between the platform's compiled directory and the product's compiled directory when the product needs to use the platform's dynamic library files. The dynamic library acquisition module is used to acquire the required platform dynamic library files based on the path of the platform compilation directory relative to the product compilation directory. The path acquisition module is specifically used for: When a product needs to use the platform's dynamic library files, if the current operating system is Windows, the manifest file created by the platform's compilation directory is obtained through the compiled executable file, and the path of the platform's compilation directory relative to the product's compilation directory is obtained based on the manifest file. When a product needs to use the platform's dynamic library files, if the current operating system is Linux or Unix, the path between the platform's compiled directory and the product's compiled directory can be obtained through the rpath marker of the compiled executable file.

7. A terminal, characterized in that, It includes a processor and a memory, the memory being used to store computer programs, and the processor being used to call and run the computer programs stored in the memory to perform the non-intrusive software development method as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the non-intrusive software development method as described in any one of claims 1 to 5.

Images