# How to use YACL with IBM Visual Age C++ for OS/2

Last update: June 20th, 1997

This file provides directions on how to build YACL and its demo programs using IBM Visual Age C++ 3.0 or later. The makefiles were contributed by Tom Satter. Thank you Tom!

## Building YACL

Here are the steps:

0. Create and change into the directory you want to install YACL in. For example, in an OS/2 command window:

`md c:\yacl`

`c: cd \yacl`

1. Unzip the file YACL0170.ZIP, preserving directories. For example:

`unzip yacl0170.zip`

or, if you use pkunzip under DOS:

`pkunzip -d yacl0170.zip`

2. Set the environment variable `YACLPATH` to point to the directory in which yacl was unzipped, e.g.,

`set YACLPATH=c:\yacl`

3. Modify the control file. Edit the file `control/ibmvacpp.ctl`. In that file, set the variable ICCPATH to point to the bin directory of the compiler. Its default setting in that file is `f:\ibmcpp`.

4. Build the libraries. CD into the directory you chose in step 0 and issue the make command in an OS/2 command window by typing

`nmake /f ibmvacpp.mak`

5. Poke around in the directory structure under basedemo and uidemo; build and try out the programs there using the make files provided. Each directory in uidemo and almost every directory in basedemo contains a VAC++-specific makefile named ibmvacpp.mak which can be used for building the demo. I have provided makefiles for most of the base demos.

## Known problems

The makefiles and patches were contributed by Tom Satter. (Thanks, Tom!) Here are some of its quirks:

- The IBM compiler does not allow the WindowProc to be a (static) member function of the window class. The workaround is to make the WindowProc a friend. (blechh!)
- Like the Watcom compiler, the IBM compiler does not like to have the main program in a library. So the main program file (mainprog.obj) is included explicitly in the makefiles for the UI demos.
- The compiler is rather slow. On my 486/66 with 28MB RAM, it needs 2 hours to compile YACL and 7 hours for the demos. (Compare that with 45 minutes under Borland C++ for compiling everything.)
- The executables it generates are large, averaging about 250K for the base demos and 800K for the UI demos. Tom says, however, that using appropriate link switches might bring down the executable size.
- The memory leak checker reports a leak of 1024 bytes in some programs, when there is no leak. This is because the VisualAge C++ iostream classes allocate memory the first time it is needed, and this memory is only destroyed after the main program is finished. This is reported as a leak by the leak checker, because the leak checker exits when the main program does.
- Visual Age C++ does not include POSIX routines for directory handling. Consequently the Directory class is not supported under that compiler.

Also, I've organized the makefiles to support manual instantiation rather than automatic, because the latter caused undefined symbols. Maybe there's a way to use automatic instantiation; I'd be delighted if you can contribute makefiles for this.