
-Building the *****Base server on win32 platforms- 
ibbuild-win32.txt last revised April 20, 2001

The latest version of this file is available at:
http://sourceforge.net/docman/display_doc.php?docid=349&group_id=9028

Please send comments and corrections to
rfm@cruzers.com or the firebird-devel mailing list at sourceforge
the firebird-devel mailing list is also available as a newsgroup at
news.atkin.com:sourceforge.firebird-devel

For more information see the firebird and interbase projects 
on sourceforge.net (http://www.sourceforge.com/projects/firebird,
http://sourceforge.net/projects/interbase)

Introduction:
	This document describes the steps required to compile the server
under windows NT 4.0, service pack 6. This information should
apply on other windows platforms, but I have not tested it.
	This document specifically refers to the 'firebird' cvs tree
on sourceforge. If you are looking for instruction for the original
source distribution from inprise, please refer to the borland web site.
Some slightly outdated information may also be found at: 
http://www.cruzers.com/~rfm/ib/ibbuild-win32-inpr.txt
	I assume that the reader already has a working knowledge
of CVS, make, unix shell, and interbase. If not, you will have to
do some self-education that is beyond the scope of this document.

NOTE: If you are on a slow internet connection, it is wise
to keep a clean copy of the CVS tree, and do the setup and
building described below in a copy. That way, if you mess up,
you can start over from scratch without downloading the whole
source tree again.

Directory structure:
I refer to the directory in which you did cvs checkout as
the build directory {BUILD_DIR}, and the directory to which the
binary release was installed as the install directory {INST_DIR}.
These directories MUST be different.

I also created a directory tree I refer to as the build database
directory {DB_DIR}. This can reside anywhere on your system,
except that it must not be the same as {BUILD_DIR}

Historically, the 'build databases' were stored on a central
server. If you see references to toolsdbs, yoda or jabba, these
were all incarnations of it. For the most part it doesn't matter,
but their should be one authoritative messages database somewhere,
otherwise the messages files will diverge, which will make
the divergent distributions incompatible.
I highly recommend the use of a separate server for the
build databases if you have multiple developers on a single
lan working with the interbase code.

Tools requirements:
 * Installed firebird 0.9.x or InterBase 6 binary. 
 * A borland C compiler (the 'free' available from the Borland
web site will work, as will Borland C builder.)
The compiler itself is not used, but the 'make' program is.
The 'implib' tool is required to make an import library that can
be used by the borland tools (if you do not need a borland 
import library, you can comment out the portion of
{BUILD_DIR}/build_win32/original/make.jrd which mentions implib)
Dmitry Kuzmenko has also reported that the 'make' provided
with Delphi 5 does not work with the makefiles.
The borland resource compiler (brc32) is also used.

 * Microsoft visual C (I used 6, but 5.x should be workable as well)

 * Cygnus cygwin32 or MKS korn shell (I wrote these instructions
based on a build using a recent (Dec 2000) cygwin. I've tried to
note what would be different if you used MKS, but since I haven't
tried with MKS, there are probably some things I missed.)

Cygwin may be installed from http://sources.redhat.com

Other unix-like tools should be usable as well. At a minimum, you
need bash or ksh, sed and cp.  A few other common unix commands are
probably also used, but with a little work you could substitute
the dos equivalents.

 * an echo.exe that behaves like the dos builtin
Here's the problem: The makefiles use echo to build temp text files. 
Unix like toolkits (MKS, cygwin) include an echo executable which
does not behave like the dos echo command (because they treat \ as
special). But the dos echo command is a built into command.com, so
borland make does not use it unless no echo.exe is on the path.
I use following quick and dirty echo.exe:
--begin echo.c
#include <stdio.h>
int main(int argc, char **argv)
{
	int i;
	for(i = 1; i < argc; i++) {
		printf("%s",argv[i]);
		if(i < argc - 1)
			printf(" ");
		else
			printf("\n");
	}
	return 0;
}
--end echo.c
If you do not use the MKS or cygwin echo for other purposes,
you can just rename (or delete) it instead of making your own.

PATH requirements:
 * The echo.exe resulting from the above C code MUST be in your path
before the cygwin or MKS echo.exe.

 * Borland make must be in your path before any other make (for
example, the one provided by MKS, CYGWIN etc.)

 * If you have the NT Resource Kit installed (it is not required, but
many developers probably have it) you should either remove the
so-called posix tools provided with it, or ensure that they are after
MKS or cygwin in you path.

 * The microsoft C and borland C bin directories need to be on your path.

 * the interbase/bin directory of the {INST_DIR} must be on the path

Databases:
Create the following file structure. The subdirectories 
should not be the same as the ones in {BUILD_DIR}
 {DB_DIR}/
	jrd/
		isc.gdb
		I just copied isc4.gdb from {INST_DIR} to isc.gdb
	msgs/
		msg.gdb
		master_msg_db
		These are actually the same database. Create them
		from the msg.gbak found in {BUILD_DIR}/misc. Really the
		makefiles and .e files should just be changed
		to refer to a single name.

 if you want to build qli
	qli/
		help.gdb (help.gbak is in {BUILD_DIR}/misc)
		master_help_db (once again these are the same file)
		NOTE: the help database provided with qli is owned by
		a user named bbandy (hi brett!). The install_qli_help
		target tries to gbak it, which requires that it be
		be owned by the user doing the build. This is builder
		by default.
		install_qli_help is fairly pointless anyway. All it
		does is gbak the help database from one place to another.

 if you want to build examples
	example5/
		empbuild.gdb 
		intlbld.gdb 
	These are copies of employee.gdb and intlemp.gdb, respectivly.
	Since they are just used by gpre, they probably don't need to
	have the data. But it doesn't hurt.

Files changed to unix format:
Depending on how you set it up, the cygwin tools may expect files to
be in unix, rather than dos format. MKS generally doesn't care.
using:
	cvs update -kb
on the following files, will makes CVS update them in binary mode.
This is a 'sticky' option, so these files will stay in binary mode
for future updates, unless you set a different -k option.
{BUILD_DIR}/
	setup_build.ksh
	setup_dirs.ksh
	build_win32/original/
			*.sed
	jrd/
		dyn_def.sed

If you use text, rather than binary mounts, you should not need to
do this. (But I use binary mounts, so your mileage may vary)

Commented build commands:
 If your not interested in building QLI or the examples,
 you can comment out the following:
 * builds_win32/original/build_lib.bat
 	comment out the four line section beginning with cd qli
    comment out the line
		make %FLAGS% -fmakefile.lib install_qli_help
	and the following if ...
	comment out the two four line sections beginning with
		cd example5

 * builds_win32/original/make.jrd
 	(note that this change must be made BEFORE running
	setup_dirs.ksh, otherwise, make the equivalent change in
	jrd/makefile.lib)

	in the install_client target, comment out the lines 
	referring to qli.exe and qli.pdb

Preparing to build for the first time:
make sure interbase server is running from {INST_DIR} not {BUILD_DIR}

make sure your {INST_DIR}/isc4.gdb has a user named builder
with password builder. (or change the ISC_USER and password
used in the build scripts)

start an MKS korn or Cygwin bash shell
make sure ISC_USER and ISC_PASSWORD set to valid values before
running setup_dirs.ksh (for metadata.gdb). As in:
	ISC_USER=builder
	ISC_PASSWORD=builder
	export ISC_USER
	export ISC_PASSWORD

Under cygwin, you must either make sure the mount where the
interbase source is has been mounted with -x (which makes all files
under that mount executable), or you must put
#!/bin/bash 
at the start of setup_build.ksh and builds_win32/original/build_no.ksh
If you do not do this, setup_dirs will give an error like
'./setup_build.ksh: file not found' The reason for this is described
in the cygwin FAQ.

Run setup_dirs.ksh {DB_DIR}

NOTE: in MKS, the .ksh extension is assumed, but in cygwin
it must be specified. If you just type setup_dirs in cygwin bash
you will attempt to run the unix setup_dirs script and fail.

Error messages from setup_dirs.ksh and setup_build.ksh:
The first time you run setup_build.ksh (via setup_dirs.ksh),
it generates a harmless error because it tries to drop
'metadata.gdb' even when it is not there.

copy 
	{INST_DIR}/SDK/lib_ms/gds32_ms.lib
to
	{BUILD_DIR}/jrd/ms_obj/client
(this allows the codes.exe and the messages tools to be built)


BUILDING:
set the environment variable IBSERVER to the root of {INST_DIR}
run build_lib.bat 
If all goes well there will be about 8000 warnings and no errors.

build_lib.bat has some options:
-DDEV makes a build with debug info, delivering the built kit
to {BUILD_DIR}/ib_debug, with associated PDB files.
Without -DDEV, an optimized build is done, delivering to
{BUILD_DIR}/interbase
-B forces and unconditional build (ignores file change dates,
by passing -B on to borland make)

I usually invoke build_lib as build_lib -DDEV > build.log 2>&1,
and then start a tail -f build.log in another window, so I have
a log file and can watch the progress.

Running the new server:
The easiest way to do this is to:
rename your {INST_DIR} and then copy {BUILD_DIR}/interbase (optimized) 
or {BUILD_DIR}/ib_debug (debug) to where your INST_DIR was.
Remember to shut down your running server first.
If you don't want to replace your existing isc4.gdb, you can
just copy the bin directory. Remember to copy lib and include as well,
if you are compiling your own applications against the installed 
kit.
To debug the server, you might want to invoke it with the -a command
line option, so it runs as an application on your desktop,
rather than a service.

When you install the new server, you need to do something with
gds32.dll, which ends up in {BUILD_DIR}/interbase/bin or
{BUILD_DIR}/ib_debug/bin.
You should either copy it to windows\system[32] (as the normal
install does) OR delete whatever gds32.dll is in system, and keep
the gds32.dll in the bin dir of the newly created build. I usually
use the latter method, since that makes it so that you can replace
all of IB (or just the bin dir) as a unit. You do have to ensure,
however, that there are no other gds32.dlls on the path that you
might pick up first.

TRADEMARKS:
All trademarks are property of their respective owners.
