C/C++ source code generated by the XBinder compiler can be compiled using any ANSI standard C or C++ compiler. The only additional option that must be set is the inclusion of the XBinder C/C++ header file include directory with the –I option.
When linking a program with compiler-generated code, it is necessary to include the XBinder common run-time library (osysrt) and the XBinder XML run-time library (osysrtxml). If the -sax option was specified, a third-party XML parser library is also required. When including an XML parser library, it is also necessary to link with an object file that provides a common abstraction layer to different vendor implementations. The distribution contains object files to interface with the EXPAT XML parser (http://www.libexpat.org) and the libxml2 XML parser library (http://xmlsoft.org). These files are named rtXmlExpatIF.obj and rtXmlLibxml2IF.obj respectively (note: different variations of this object file exist for the different library configurations described below). It is possible to create your own implementation of this interface file if linking with a different XML parser library is desired. Source code is provided for the default implementations which can be used as a guide for writing your own implementation. See the XML Parser Interface section for details on this interface.
If the -dom option was specified, the DOM library (osysrtdom) is also required. Using the -dom option implies using the -sax option, so an XML parser library and interface object must also be included as described above. A DOM API library must also be used. XBinder includes a DOM API library (osysrtdomapi) which interfaces with the libxml2 XML parser library. You may also write your own implementation using another XML parser library. See the XML C DOM Interface section for more details on this interface.
For static linking on Windows systems, the names of the library files are osysrt_a.lib and osysrtxml_a.lib. On UNIX/Linux, the library names are libosysrt.a and libosysrtxml.a. The library files and XML library interface object files are located in the lib subdirectory. For UNIX, the –L switch should be used to point to the subdirectory path and –losysrtxml and –losysrt used to link with the libraries. For Windows, the –LIBPATH switch should be used to specify the library path.
There are several other variations of the C/C++ run-time library files and XML parser library interface files for Windows. The following table summarizes what options were used to build each of these variations:
| Library Files | Description |
|---|---|
|
osysrt_a.lib |
Static single-threaded libraries. These are built with the –ML option. These are not thread-safe. However, they provide the smallest footprint of the different libraries. (Note: <lib> would be replaced with the name of the XML parser library to be used. For example, rtXmlExpatIF_a.obj for the EXPAT library.) |
| osysrtxml.lib rtXml<lib>IF.obj | DLL libraries. These are used to link against the XBinder run-time DLL library (osysrtxml.dll). Note that this single DLL holds code from all of the individual libraries that may be used when linking statically. |
| osysrtmt_a.lib osysrtxmlmt_a.lib osysrtdommt_a.lib osysrtjsonmt_a.lib rtXml<lib>IFmt_a.obj | Static multi-threaded libraries. These libraries were built with the – MT option. They should be used if your application contains threads and you wish to link with the static libraries (note: the DLL’s are also thread-safe). |
| osysrtmd_a.lib osysrtxmlmd_a.lib osysrtdommd_a.lib osysrtjsonmd_a.lib rtXml<lib>IFmd_a.obj | DLL-ready multi-threaded libraries. These libraries were built with the –MD option. They allow linking additional object modules in with the XBinder run-time modules to produce larger DLL’s. |
For dynamic linking on UNIX/Linux, a shared object version of each run-time library is included in the lib subdirectory. This file typically has the extension .so (for shared object) or .sl (for shared library). See the documentation for your UNIX compiler to determine how to link using these files (it varies for different types of UNIX systems). Typically, if a shared object version of a library exists in the linker library path, the linker will choose it over the static archive library version. So if you want to link with the static libraries, it is usually sufficient to move the shared object files somewhere else (or delete them).
The XBinder distribution contains some utilities to make the creation of build scripts easier. These utilities are as follows:
A -genmake command line option to generate a sample makefile to build the files generated by a specific compilation, and
Make include files (file ending with extension .mk) that contain common symbols for many of the options described above.
The –genmake option will cause a makefile to be created that will compile all of the generated source files into object files using the configured C or C++ compiler (the compiler is configured in the platform.mk file, see below). This makefile will contain dependencies for all included header files. The default generated makefile will be compatible with the GNU make utility and should be portable to most UNIX/Linux systems. The –w32 command line switch can be used to generate a makefile that is compatible with the Microsoft Visual Studio nmake utility.
The two primary make include files are platform.mk and xmlparser.mk. The platform.mk file contains all of the common definitions for a particular platform. These include the C or C++ compiler and linker to be used and the compile/link options. The xmlparser.mk file contains common definitions for interfacing with an XML parser library. It is possible to change XML parser library implementations by simply changing the definitions in this file.
See the makefile in any of the sample subdirectories of the distribution for an example of what must be included to build a program using generated source code.