1 implementation plan for various components
1.1 Implementation of third-party development kits
The third-party development package has the following characteristics: Each product has its own directory structure, organization's way is not uniform, direct use will increase the complexity of reference and dependencies; the product catalog has a very large number of files, If you are directly incorporated into the configuration management, the overhead of adding source control is large, and when the original file is replaced when the version is upgraded, it is very cumbersome and easy to erroneously, but the uncontrolled words will cause third-party development package version conflicts and installation path inconsistent. Problem; reference to third-party development packages in the project, usually do not directly use its source code, but linked to its compiled static library.
In response to the above features, the source code structure organization of third-party development kits is shown in the following figure:
table of Contents
Description
Note
zipped
The release package of third-party products, usually ZIP compressed files
Incorrecting configuration management
build
Build a script and IDE project file
Incorrecting configuration management
Test
Verify that third-party products have successfully compiled, installed test code
Adjust the configuration management if you write or modify the test code yourself
Build_Space
Temporary place for unpacking, compiling and installation for third-party products
Temporary directory, no configuration management
Include
Third-party product public header file (ie interface) installation target directory, the other components of the project add a header file to its header file to the header file containing the lookup path by setting an environment variable.
It is usually automatically copied from the construction script in the installation step.
Lib
Third-party products ultimately provide static libraries and dynamic libraries referenced by other components of the project
It is usually compiled by the build script, and the installation step is generated.
DOC
Third-party product user reference document
It is usually automatically copied from the construction script in the installation step.
bin
executable file
It is usually compiled by the build script, and the installation step is generated.
In this scenario, incorporating the distribution package (ZIP compressed file) of a third-party product, and can automatically build and install a third-party product. The project will maintain its different versions of the release package in each baseline, and version control is very simple, and the execution of the build script ensures that the correct release is installed to the target development space for the project other component reference. Third-party products although the directory itself is different, the target directory structure after its installation is exactly the same, and other components only need to find head files under include, and find the library files that need to be linked under libs. Quote Dependent relationship is simple Ming.
Build a script to perform steps:
First, initialization, ready to compile the tool configuration; Clean, get clean work space; complete build preparation (-prep), create some temporary directory (build_space) and target directories (incrude); Unpack, extract the third-party product to build_space; automatic compilation (Autobuild), generate target libraries and executables under the build_space directory; open the installation process (INTERL), will open header file (ie interface file) Automatically copy to include, copy the user reference document to the DOC, copy the static library and dynamic library to the lib, copy the executable to BIN, and finally set an environment variable to the current root directory of the development package; Perform test preparation (-TESTPREP), from a third party release package, copy to TEST; TestBuild, generate test execution files; implement test (TEST), verify third-party products installation, Using its components can be compiled normally and can be tested. Quote Example of a third party release package:
After performing the build script of the log4cplus development package (guarantees the installation process install correctly), add an attribute record in the D: /Development_home/building.workspace/ env.properties file getnv.log4cplus_root = k /: // PCHL_V1_DEV //// Libraries // log4cplus; and add an environment variable (limited to Windows NT platform) to the current root directory log4cplus_root = K: / PCHL_V1_DEV / LIBRARIES / LOG4CPLUS.
The reference component If you use the Ant script, you will reference the env.properties file in the script, then in the compilation task, use the getenv.log4cplus_root property, add $ {getenv.log4cplus_root} / include path, and use in the libset segment $ {getenv.log4cplus_root} / lib directory directs static link libraries such as LOG4CPLUS.LIB.
The reference component If you use MSVC6 IDE, add% log4cplus_root% / include header file search path and% log4cplus_root% / lib library file search path.
Use the following format in the source code of the reference component to include Log4CPlus public header files:
#include
#include
