# The contents of this file are subject to the Interbase Public
# License Version 1.0 (the "License"); you may not use this file
# except in compliance with the License. You may obtain a copy
# of the License at http://www.Inprise.com/IPL.html
#
# Software distributed under the License is distributed on an
# "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express
# or implied. See the License for the specific language governing
# rights and limitations under the License.
#
# The Original Code was created by Inprise Corporation
# and its predecessors. Portions created by Inprise Corporation are
# Copyright (C) Inprise Corporation.
#
# All Rights Reserved.
# Contributor(s): ______________________________________.

This document gives some information about the InterBase product
build on UNIX (including Linux) platforms.

Created: 08-Aug-2000, bsriram

-------------------------------------------------------------------------------
*** How to build an InterBase kit on an UNIX platform ***

Pre-requisites:
##############
	- An installed InterBase kit in the build machine.
	  This will allow us to use 'gpre', 'gds_lock_mgr' etc.
	  You can download an InterBase runtime kit from the 
	  following site: http://www.inprise.com/interbase
	- Disk space: around 200 MB
	- Download the source tree from the CVS repository in 
	  SourceForge under the project Interbase. Further details
	  on the project can be obtained at 
	  http://www.sourceforge.net/project/Interbase

Assumptions:
############
	- You are logged into the 'build' machine for the respective
	  platform. 
	- platform for build is LINUX
	- Let us call the InterBase Runtime kit installed directory 
	  as INTERBASE_RUNTIME
	- Let us call the local InterBase CVS source tree directory
	  as LOCAL_CVS_SOURCE_TREE
	- Start the Interbase runtime server 
               (if you installed SuperServer)
	- It is recommended that you install a CLASSIC architecture 
	  of Interbase runtime on the build machine before 
	  doing the build
	- Include '.' in your $PATH (in order to execute scripts in
	                             in the current directory)

Actions to be followed:
######################
	- cd $LOCAL_CVS_SOURCE_TREE
	- chmod +x setup_dirs /* Assign 'x' perms to the script */
	- setup_dirs LINUX DEV 
	  /* The 1st argument to 'setup_dirs' should be one of the 
	     valid platforms supported. Just run 'setup_dirs' with
	     no args. to get a list of valid platforms. */
	- cd $INTERBASE_RUNTIME
	- cp include/iberror.h $LOCAL_CVS_SOURCE_TREE/interbase/include
	- cp bin/gpre $LOCAL_CVS_SOURCE_TREE/interbase/bin
	- cp bin/gds_lock_mgr $LOCAL_CVS_SOURCE_TREE/interbase/bin
	- cp lib/gds.so $LOCAL_CVS_SOURCE_TREE/interbase/lib
	    /* Copy 'gpre' and the shared library for 
	       pre-processing Embedded SQL code. 'makefile'
	       access source/interbase/bin path */
	  /* On Linux the gds.so is available in /usr/lib/libgds.so */
	- cd $LOCAL_CVS_SOURCE_TREE
	- cd jrd
	- make codes
	- codes 
	  /* This will create ibase.h and other needed include files */
	- cd ..
	  /* decide which architecture build you want */
	- build_kit builds [SUPER | CLASSIC] 

-------------------------------------------------------------------------
*** Build notes ***

- The script 'setup_dirs' builds some databases that are required 
  by the build scripts and GPRE (pre-processing utility). You may 
  find backup (transportable format) of these databases in the 
  CVS source tree sub-directory builds/original/dbs

- problems with pyxis/edit.c
  If you are unable to pre-compile pyxis/edit.e, please download 
  the one from the CVS tree repository on SourceForge. There are 
  currently some problems in pre-compiling pyxis/edit.e, hence a 
  pyxis/edit.c is available for build convenience.

------------------------------------------------------------------------
*** 'SUPERSERVER' architecture build comprises these parts ***

- InterBase CLASSIC is first built. i.e. the 'gds' library for CLASSIC 
  is built first and all the executables are linked to it. This 'gds' 
  library is named gdsmt.so.0 on Solaris and gds.so.0 on Linux.

- Under the 'source/super' directory, there are multiple 
  sub-directories (jrd, remote, dsql etc.). The source files in these 
  directories are symlinks to the sources in the CLASSIC tree but the 
  compilation is done with the 'SUPERSERVER' OR the 'SUPERCLIENT' 
  #define turned on. 

- The next library to be built is the library to which all the clients 
  (isql etc.) will link to. This library is gdsmt.so.1 on SOLARIS and 
  gds.so.1 on Linux.
  The library currently contains code for the clients to go through the
  REMOTE component and talk to the 'SUPERSERVER' through a loopback
  implementation. 
  Once this library is built, it is moved over to interbase/lib 
  directory. The /usr/lib/libgdsmt.so link needs to be pointing to 
  this 'SUPERCLIENT' library. It is called so, because, it is a CLIENT 
  interface to the 'SUPERSERVER'.
  The 'SUPERCLIENT' library is built with objects that have been 
  compiled with the '-DSUPERCLIENT' option to the compiler.

- The 'SUPERSERVER' executable 'ibserver' is then built. This 
  requires building the 'gds_ss.a' (a static library). The 'gds_ss.a'
  library contains all the object files (engine etc.) to talk to the
  database and the REMOTE component. 'ibserver' is linked statically
  with 'gds_ss.a'. Since only one process is going to use this 
  'gds_ss.a' it is not be a shared library. The 'gds_ss.a' library 
  is built in source/super/jrd and 'ibserver' is built in 
  source/super/remote. The 'gds_ss.a' library is built with objects 
  that have been compiled with the '-DSUPERSERVER' option to the 
  compiler.
------------------------------------------------------------------------
