OGDI Build Instructions

Building OGDI on Unix/Linux

OGDI is built based on GNUmake configuration files. The following describes how to create a configuration file with configure and use it to build.

Set the TOPDIR environment variable to point to the home directory of the OGDI source tree.
```
   eg. 
   TOPDIR=/usr/ogdi-3.1.3
   export TOPDIR
```
Run configure.
```
   ./configure
```
By default OGDI will be built with internal versions of libz (compression), expat (XML Parsing) and PROJ.4 (projections). External copies of these libraries can be selected for use with appropriate configure options. For instance, the following directives would use external versions of libz in /usr and PROJ.4 found in /usr/local. Additional details on configure options follows appear later in this document.
```
   ./configure --with-zlib --with-proj=/usr/local
```
Build with make (GNUmake is required).
```
   make
```
NOTE: on some platforms you will need to add the shared libraries to your LD_LIBRARY_PATH for the link phase to complete.
```
   LD_LIBRARY_PATH=$TOPDIR/bin/`uname`
   export LD_LIBRARY_PATH
```
Install. By default OGDI libraries, executables and include files are installed into /usr/local/lib and /usr/local/bin and /usr/local/include respectively. Use --prefix with configure to control target install location.
```
   make install
```

Special Issues on Unix/Linux

The built-in version of PROJ.4 is ancient, and it is generally advised that current versions of PROJ.4 from www.remotesensing.org/proj or a mirror be used. It should be built and installed before OGDI is built, and the --with-proj configure switch used to select it.
Most unix system already have libz pre-installed in /usr/lib. It is generally advised to use the system libz via the --with-zlib configure switch to avoid conflicts.
The OGDI build tree segregates object code, executables and libraries based on the target platform name. By default the TARGET environment variable is set based on the result of the uname command if not already provided. Thus it should be possible to build executables for several platforms out of the same source tree if desired.
The CFG environment variable can be used to cause OGDI to be built with debugging information by setting it to "debug". By default release (optimized) builds are prepared.
The following special configuration options exist for use with OGDI. Just giving --with-proj (or --with-zlib or --with-expat) will cause the package to be searched for in standard locations like /usr/lib and /usr/include. Alternatively a path to a tree such as /usr/local can be given as an argument. To force use of particular library or include directory use the lib and inc options can be used. The lib variable should contain the link directive (ie. --with-projlib="-L/usr/local/lib -lproj" or --with-projinc=/usr/local/include.
```
  
  --with-proj[=ARG]       Utilize external PROJ.4 support
  --with-projlib=path     Select PROJ.4 library
  --with-projinc=path     Select PROJ.4 include directory
  --with-zlib[=ARG]       Utilize external ZLIB support
  --with-zliblib=path     Select ZLIB library
  --with-zlibinc=path     Select ZLIB include directory
  --with-expat[=ARG]      Utilize external Expat library, or disable Expat.
  --with-expatlib=path    Select Expat library
  --with-expatinc=path    Select Expat include directory
```
Many normal configure build options work with OGDI including the --prefix switch to set the install tree location, and setting environment variables for CC, CFLAGS and so forth to influence build options used.
The OGDI configure tries various things to build shared libraries, but shared library generation works best for platforms using the GNU C compiler and related tools. On platforms where shared library building does not work, static libraries will be used.
Custom build files can be constructed for problem platforms by copying something an existing configuration and updating it. For instance, copy config/linux.mak to config/tru64.mak and then update according to platform requirements. Then set the TARGET environment variable to the platform name (ie. tru64) and build - skipping configure completely.

Building OGDI on Win32

Building OGDI on Win32 is accomplished using a predefined build configuration file. Use the following steps.

The build environment requires the Cygwin tool chain. These provide Unix-like shell and make environment. They can be downloaded for free from www.cygwin.com. Note that the compiler from Cygwin (gcc) is not used on win32.
The Visual C++ compiler from Microsoft is used (version 6.x normally).
Because the Visual C++ compiler is run from the command line, it is generally necessary to predefine some environment variables setting the path, include path and link path. The installed Visual C++ compiler usually has a BAT file at a path something like C:\Program Files\Visual Studio\VC98\bin\VCVARS32.BAT. Run this via AUTOEXEC.BAT or run it in an MSDOS window before launching the cygwin window from it to inherit the values.
The configure script doesn't work on Windows. Just set TARGET to win32 and run make without running configure.
```
 export TOPDIR=C:/ogdi-3.1.4
 export TARGET=win32
 export CFG=release
```
Build normally in the Cygwin shell using GNUmake.
```
make
```
The make install target does not work in a meaningful way on win32. Copy files as needed from the bin/win32 directory for deployment.

Building Tcl Support

The Tcl wrappers for OGDI are in the devdir/ogdi/tcl_interface directory. To build them it is necessary to define the TCL_INCLUDE variable in the platform specific makefile. For instance, adding the following to devdir/config/linux.mak may work on Linux.

TCL_INCLUDE = -I/usr/include/tcl8.3

Once this is done, just type make in the tcl_interface directory. It should (after many warnings) build a $TOPDIR/bin/$TARGET/libecs_tcl.so file. This can be loaded into Tcl using a command like:

% load "$env(TOPDIR)/bin/$env(TARGET)/libecs_tcl.so"

If you get a complaint about not finding Ecs_tcl_Init(), add the following to devdir/ogdi/tcl_interface/ecs_tcl.c. It seems some versions of Tcl require a different naming convention for the main entry point.

int Ecs_tcl_Init(Tcl_Interp *interp )
{
    return Ecs_Init( interp );
}