The Makefile
FLAIM, XFLAIM, and Toolkit are all built using GNU Make. There is a Makefile in each of the major subdirectories: flaim, ftk, and xflaim. The Makefile automatically determines the platform that is being built (except for Netware, which must be cross-compiled on Windows). It also tries to automatically determine if the build should be a 64 bit or 32 bit build. It does this by looking for various environment variables. From environment variables such as OS, OSTYPE, RPM_OS, and so forth, it determines platform.
Platform Support
Three things are automatically detected in the Makefile: host platform, target platform, and whether 32 bit or 64 bit builds are supported. In general, the host and target platforms are the same. The only cross compiling that is done is when doing a netware build. How the Makefile detects these platforms is described below.
- Windows. Windows is detected by looking for the OS environment variable containing either a "WIN" or "Win" string.
- Netware. Builds for Netware must be done on a Windows machine. The user must specify a target of "nlm" on the make command line.
- Linux and Unix. For Linux and Unix systems, the environment variables OSTYPE is examined. If OSTYPE is not present, RPM_OS is examined. If RPM_OS is not present, the Makefile attemps to run the command "uname -s" to get a string it can examine. Based on the contents of the string from one of these places, it will determine what flavor of Linux of Unix is being built. These are as follows:
- Linux. Looks for the strings "Linux" or "linux".
- Solaris. Looks for the string "solaris" or "SunOS".
- Mac OS X. Looks for the string "darwin" or "Darwin"
- AIX. Looks for the string "aix".
- HP-UX. Looks for the string "hpux".
32 and 64 Bit Builds
The Makefile will automatically detect whether to do a 64 bit build or a 32 bit build based on strings it finds in the following environment variables: PROCESSOR_ARCHITECTURE, RPM_ARCH, or HOSTTYPE. The environment variables are examined in the order specified. If none of these environment variables are present, the Makefile will attempt to execute the "uname -p" command to get a string it can examine.
Once the Makefile has a string, it looks for the following sub-strings to determine the type of processor, and whether it supports doing both 32 bit and 64 bit builds. If a 64 bit build is supported, that is the type of build that will be done by default. Otherwise, a 32 bit build is done. Note that a 32 bit build may be requested on a 64 bit processor if the user specifies a target of "32bit" on the make command line.
- x86_64. x86 processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
- x86. x86 processor, supports 32 bit build only.
- ia64. Alpha processor, supports only 64 bit builds.
- s390x. s390 processor, supports 32 and 64 bit builds, defaults to 64 bit.
- s390. s390 processor, supports only 32 bit build.
- ppc64. PowerPC processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
- powerpc. PowerPC processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
- Power. PowerPC processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
- rs6000. PowerPC processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
- ppc. PowerPC processor, supports only 32 bit builds.
- sparc. SPARC processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
- hppa. HPPA processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
- 9000. HPPA processor, supports 32 bit and 64 bit builds, defaults to 64 bit.
NOTE: When doing a Netware build, the processor is x86, and only a 32 bit build is supported.
Default Compiler, Linker, etc. Tools Used
Unless otherwise noted, compilers, linkers, and so forth are expected to be found in the search path. Tools used for the various platforms are as follows:
- Windows. Compiler: cl.exe - must be version 7 or 8. Linker: link.exe. Library tool: lib.exe.
- Netware. Compiler: wpp386.exe (Open Watcom compiler). Linker: wlink.exe. Library tool: wlib.exe. NOTE: These tools are found using either the WATCOM or WC_DIR environment variables. They are expected to be in either the $(WATCOM)\binnt directory or the $(WC_DIR)\binnt directory.
- Linux. Compiler and Linker: g++. Library tool: ar.
- Mac OS X. Compiler and Linker: g++. Library tool: libtool.
- Solaris. Compiler and Linker: CC. Library tool: ar. Shared library linker: ld. NOTE: The Makefile will run the command "CC -V" to determine if the compiler is the Sun Studio compiler, in which case it will use extra compiler flags that are known by that version of the compiler.
- AIX. Compiler and Linker: xlC_r. Library tool: ar.
- HP-UX. Compiler and Linker: aCC. Library tool: ar.
NOTE: For Unix platforms, the default compiler may be overridden by specifying a target of "usegcc" on the command line, in which case the GNU compiler will be used.
Debug and Release Builds
The user may specify a Debug build by including a target of "debug" on the command line. A release build is specified
merely by omitting the "debug" target, or by specifying a target of "release" on the command line. A release build is
the default type of build. Debug builds include flags for debugging as well as other debug conditions (assertions, etc.)
that will slow down the execution of the code. Release builds are optimized for best performance and may not be compiled
for debugging.
Other Make Options
The user is allowed to specify the following targets to override default behaviors:
- usegcc. Force the use of the GNU compiler on Solaris, etc. NOTE: The GNU compiler is used by default on Linux platforms.
- 64bit. Force a 64 bit build. This is only valid if the host platform supports doing 64 bit builds.
- 32bit. Force a 32 bit build. This is only valid if the host platform supports doing a 32 bit build.
- ring0. Force a Netware build to be for execution in ring 0.
The Build Area
All binaries (object files, libraries, and executables) are stored in the "build" subdirectory. If you are building FLAIM, it will be flaim/build. If you are building XFLAIM, it will be xflaim/build. If you are building Toolkit, it will be ftk/build. Underneath the "build" sub-directory is the following sub-directory structure:
<target>/<build-type>
The <target> sub-directory name has three components: <target_os>-<target_processor>-<target_bits>
- <target_os> will be one of the following: "win", "linux", "solaris", "osx", "aix", "hpux", or "netware".
- <target_processor> will be one of the following: "x86", "ia64", "s390", "powerpc", "sparc", "hppa"
- <target_bits> will be either "32" or "64".
The <build-type> sub-directory will be either "debug" or "release".
Examples:
- win-x86-32/debug. 32 bit debug build for Windows on x86 processor.
- linux-powerpc-32/debug. 32 bit debug build for linux on powerpc processor.
- solaris-sparc-64/release. 64 bit release build for solaris on sparc processor.
Underneath the <build-type> sub-directory, there are the following sub-directories:
- test. This is where all of the test executables will go. Unit tests will be run in this sub-directory.
- test/obj. This is where all of the object files for the test executables will go.
- util. This is where all of the utility executables will go.
- util/obj. This is where all of the object files for the utilities will go.
- sample. This is where the sample program executable will go.
- sample/obj. This is where the object files for the sample program will go.
- lib/static. This is where the static library will go.
- lib/static/obj. This is where the object files for the static library will go.
- lib/shared. This is where the shared library will go.
- lib/shared/obj. This is where the object files for the shared library will go. NOTE: This is only used when building the Windows shared library. For Windows, the source files are compiled twice, because the compiler options used for a shared library need to be different than those used for a static library. The shared library has specific options for exporting symbols. For all other platforms, the object files for both the shared library and the static library are the same, so they will come from the lib/static/obj sub-directory.
Cleaning the Build Area
To "clean" the build area means that all object files, libraries, and executable files are deleted. This allows developers to ensure that everything is correctly built. The debug and release build areas must be cleaned separately - there is no command to clean them both at the same time. The "clean" commands are as follows:
- Clean the debug area: "make clean debug"
- Clean the release area: "make clean" or "make clean release"
NOTE: The "clean" target cannot be used with other targets. In other words, it is not possible to do a single command that would clean the build area and then build the libraries or utilities or test programs. For example, the following command is illegal because it has both the "clean" target and the "test" target specified:
make debug clean test
Although it would have been possible to allow this command, it was decided that it was safer to disallow it - so that a developer doesn't accidentally always start a clean build. Cleaning is deliberately designed to be a separate step from building.
Building FLAIM, XFLAIM, or Toolkit Libraries
To build FLAIM libraries, the user must be in the "flaim" sub-directory. To build XFLAIM libraries, the user must be in the "xflaim" sub-directory. To build the Toolkit libraries, the user must be in the "ftk" sub-directory. Once in the desired sub-directory, the make commands to build libraries are as follows:
- Build Debug Libraries: "make debug" or "make debug libs"
- Build Release Libraries: "make" or "make libs" or "make release" or "make release libs"
Building FLAIM, XFLAIM, or Toolkit Utilities
As with building libraries, the user must be in the appropriate sub-directory to build utilities (flaim, xflaim, or ftk). Once in the desired sub-directory, the make commands to build utilities are as follows:
- Build Debug Utilities: "make debug all"
- Build Release Utilities: "make all" or "make release all"
NOTE: The "all" target will build all utilities. Individual utilities may be specified instead of "all". Valid utility targets are as follows:
- FLAIM Targets. checkdb, rebuild, view, sample, dbshell, gigatest. NOTE: sample is the sample program.
- XFLAIM Targets. checkdb, rebuild, view, sample, xshell. NOTE: sample is the sample program.
- Toolkit Targets. There are no utilities for the toolkit.
NOTE: There is no need to build the libraries separate from the utilities. The required libraries will be built with these commands if they have not already been built.
Building and Running FLAIM, XFLAIM, or Toolkit Unit Tests
As with building libraries, the user must be in the appropriate sub-directory to build and run unit tests (flaim, xflaim, or ftk). Once in the desired sub-directory, the make commands to build and run unit tests are as follows:
- Build and Run Debug Unit Tests: "make debug test"
- Build and Run Release Unit Tests: "make test" or "make release test"
NOTE: There is no need to build the libraries separately from the unit tests. The required libraries will be built with these commands if they have not already been built.
