| PathEngine home | previous: | next: |
The GCC based platform specific code packages enable the PathEngine run-time library to be built on various operating systems and architectures where the GCC toolchain is available as a standard compilation environment.
Python build scripts are used on these platforms, because of the generally good availability of the Python interpreter, and to avoid problems with differences in makefile interpretation between platforms.
The GCC based platform specific code packages include platform specific code directories, plus python build scripts and xml project configuration files.
The packages should be extracted over the top of the base full source package,
ensuring that the release numbers for the two packages match.
The xml project configuration files will then be extracted into each project directory.
The build scripts and configuration files are duplicated across all GCC based packages. It is ok for these to be overwriten, then, in the case of installation of a second GCC based package.
Binaries are not included so all static libraries will need to be built from source.
Building the source code requires python and a recent version of GCC, with C and C++ standard libraries installed.
Python is nowadays often included as standard with Linux and FreeBSD distributions.
If not then it can be downloaded and installed from www.python.org.
The build setup is tested against Python 2.4, but should work with Python 2.5 without any issues, and is likely to also work with some older versions of Python.
Before building the source code, the following environmental variables need to be set:
On some Linux distributions (or on OSes), shared objects require the generation for position independant code,
with the -fPIC option.
But this option can add some significant overhead, and is therefore not included by default.
Instead, additional platform codes have been added with the option enabled.
These additional codes are formed by adding an '_SO' suffix to the base platform code.
When building shared objects on distributions or OSes where the -fPIC option is required, use GCCx86_SO instead of GCCx86 or GCCx64_SO instead of GCCx64.
Change directory to 'SDKRoot/python/buildScripts' and type "python Make.py PathEngine".
After the first build the build scripts will check dependencies and only recompile objects that need to be recompiled.
The above build operation should generate a file 'PathEngine.so',
in a directory created for 'SDKRoot/build/Configuration_
platform/PathEngine', where Configuration is replaced by
the configuration being built (e.g. 'Debug' or 'Release'), and platform
is replaced by the code for the platform being built.
(So the build result for a debug build, on x64 Linux, is at 'SDKRoot/build/Debug_GCCx64/PathEngine/PathEngine.so'.)
This is a shared object binary, essentially the Linux equivalent of a Windows DLL.
Refer to
Static libraries can also be found in directories under 'SDKRoot/build/',
and these can be used for direct linkage to PathEngine.
Refer to
Although a run-time library .so is not required when using static linkage, use the command line for building the run-time library, nevertheless, as this will then generate all the required static libs.
Depending on how GCC is setup, it may be necessary to modify the compile command.
This can be done by modifying the compileCommand() function, in 'SDKRoot/code/buildScripts/PlatformConfig.py'.
(And this compile command can also be modified to change the level of optimisation, and so on.)
Note that the build scripts don't check themselves as a dependency, so it may be necessary to perform a full rebuild
after script changes.
This can be done by deleting all the intermediate directories generated by a previous build command.
| Documentation for PathEngine release 5.16 - Copyright © 2002-2008 PathEngine | next: |