OWLNext Home

~ Building OWLNext Libraries ~


Home
About OWLNext
Getting started
Prerequisites
Patching
Building
Configuring
Tutorials
Documentation
Downloads
Articles
Links
Discussions

Building

You may find easier to build OWL Next libraries using the OWLMaker program, which provides graphical user interface for choosing the libraries, providing the required .obj/.lib files and setting various options. If so, download, install and run the program and use the wizard. If you don't want or can't use OWLMaker, then follow the steps below.

Step 1: Extract the build support files

Extract "obj32b.zip" or "obj32v.zip" in "c:\owl". Put the contents in the applicable directory, e.g. "\owlwfi" for a non-debug version.

Step 2: Select libraries

First, you need to decide what libraries you want. There are many possibilities, even with the unmodified Borland OWL. To see which ones you've installed, run this command:

dir \bc5\owl*.lib /s /p

I have nine Borland OWL libraries installed, and there are probably others on the CD.

You may not actually be using all the libraries you've installed. To see which you need for a particular project, first set "Options | Environment | Project View | Show run-time nodes" in the IDE, then load your project and look at each target node for lib files whose names begin with "owl". For instance, in one project, I have some nodes that use "owlwfi.lib", and some others that use "owldwfi.lib". So I need to build both of those.

To interpret those .lib names, break them down this way:

OWL [D] W [F|L|T] [I] [U]
OWL
means, well, OWL.
D
means debugging is enabled.
W
probably means windows.
F
means 32-bit flat model.
L
means 16-bit large model.
T
means multi-threaded.
I
means import library to accompany a DLL.
U
means Unicode.

Step 3: Modify the appropriate batch file

In "c:\owl\source\owlcore" there's a make file named "makefile" and batch files "gnuowl.bat", "bcowl.bat", and "mscowl.bat" that drive the make file. Choose the appropriate batch file for the compiler you plan to use, and take a look at its contents. You see many different examples to build various libraries. Remove the rem comment token from the ones you want, and insert rem before the ones you don't want, or make up your own.

Note: It may be better to edit a copy of the batch file, as the supplied batch files may be modified by a patch, and the patch program will fail if the file is modified.

Example

For example, here's what I did to build OWLWFI.LIB and its accompanying DLL:

c:\bc5\bin\make -c -K DLL=1 WIN32=1 -DOWLROOT=C:\OWL >make.out

I added "-K" to keep the temporary files created by make (useful for tracking down problems), and I redirected make's output to a file because I found it too taxing to try to read it as it scrolls by on the screen. The options I passed to the make file just say that I want to make the source in "c:\owl" into a 32-bit DLL.

Make file options

Here are the most important makefile options:

-DOWLROOT=C:\OWL
Always specify the location of your OWL Next source. If you don't, you get a default that you probably won't like.
DLL=1
Build a DLL instead of a static library. Omit this parameter to build a static library.
WIN32=1
Build a 32-bit library. [Does WIN16 work?]
ILINK=1
Use the incremental linker. Omit this parameter for BC++ version 5.02 or earlier, which have a buggy incremental linker.
DIAGS=2
Diagnostic build enables tracing information [Does the value 2 ever matter? Or is it just defined or not defined?]
DEBUG=2
Build library with full debug information. This lets you trace into OWL with the debugger, which can be very handy. But it also makes the library much larger; for that reason, Borland by default doesn't install debug builds, although they put them on the CD. [Does the value 2 ever matter? Or is it just defined or not defined?]
CODEGUARD=2
Build library with CodeGuard enabled. Omit this unless you have a reason to use CodeGuard on OWL itself. You can use CodeGuard on your own code and link it to a non-CodeGuard version of OWL.
-DCOMPILE_ASM
Use this only if you have TASM installed; otherwise, you'll get errors. If you don't use this parameter, you need to install the precompiled object files in "obj32b.zip" or "obj32v.zip".
-DOWLSECTION
This option is recommended. Many source files are separated into sections so that each section can be compiled into a separate object file. The linker uses only the sections your code needs, so that linking can be faster and your executable can be smaller for static builds. There is no drawback to using sectioning.
-D_USE_OWL_CM_EXIT
This is the correct value for Borland C++ 5.02. Borland C++ Builder and Borland C++ have conflicting definitions for CM_EXIT. If you are using Borland C++ Builder, instead use -D_USE_VCL_CM_EXIT.
-DBI_STD_RTL
[Is the purpose of this parameter only to recognize xalloc exceptions?]
-DBI_STD_STRING
This option is not recommended. It forces OWL to use the old non-ANSI string class in <cstring.h>. That means you cannot easily use a string class that conforms to the standard in your own code. But you may wish to use this parameter if your code depends on the old Borland class.

Step 4: Build selected libraries

Important: Make sure the file OWLROOT.INC contains correct path to the root of OWL Next

Run the batch file you just modified to build the selected libraries for OWL Next.

Further help and information

If you encounter any problems, please post them to the OWL Next mailing list (go to Subscribe/Unsubscribe/Preferences).



Last updated: April 2005


Hosted by
SourceForge Logo