Before V0.9.12, these variables had to be set externally before building. This has been changed; the environment is now set exclusively through the config.in file in the main XWorkplace directory.

If these values not set correctly, you'll get errors from the makefiles (certain checks are built into those), or compilation or linking will fail.

1. CVS_WORK_ROOT must point to the root of your CVS working directories. The XWorkplace makefiles now (V0.9.6) assume that all your projects (most importantly, XWorkplace and XWPHelpers) are located in subdirectories of a single directory. (This is useful for working with CVS in the first place, so this shouldn't be much of a requirement.)

   This variable must point to the parent directory of xworkplace and xwphelpers. The makefiles will set a number of other environment variables based on that variable to locate the XWorkplace and XWPhelpers source tree bases.

   Example: SET CVS_WORK_ROOT=K:\cvs

2. TKBASE and VACBASE are new with V0.9.12 and must point to the base directories of your Toolkit and VisualAge C++ installations, respectively. Specify the parent directories of h and include. This is because the build process no longer relies on your INCLUDE environment variable, but specifies everything on the compiler and linker command lines.

3. SMBASE is new as of V1.0.9 and provides an alternative to copying SOM dlls from one version of the Toolkit to another. It must point to the base directory of the SOM compiler you are using. It defaults to the som subdirectory in TKBASE but can be changed to point at another version of the compiler (e.g. x:\toolkit40\som).

4. XWPRUNNING must point to an existing XFolder/XWorkplace installation. Since the makefiles first create all the files in bin\, this is not suitable for testing your code, because XWorkplace expects a lot of files at fixed locations relative to the directory where XFLDR.DLL resides. Most makefiles will copy the target files to the directory pointed to by this environment variable (after unlocking executables), so after rebuilding, you can simply restart the WPS, and your new code will be running in the WPS.

   Do one of the following:

   • Install the latest XWorkplace binary WarpIN archive. Set XWPRUNNING to the same directory which you specified as the target path to WarpIN.
   • Alternatively, copy the entire "release" subtree to some new location and specify that location with XWPRUNNING to start.
   XWPRUNNING must point to the parent directory of bin\, help\ etc. in the XFolder/XWorkplace installation tree.
   Example: SET XWPRUNNING=J:\Tools\XWorkplace

5. If XWP_DEBUG is defined (to anything), XWorkplace will be compiled and linked with debug code enabled.

   This will have quite a number of consequences since this will pass the __DEBUG__ define to the compiler, to which many code parts react. For example, only if that flag is defined, PmPrintf calls will be compiled. See "Debugging XWorkplace" for details.

   IMPORTANT NOTE: If you compile the debug version, you must have the PMPRINTF DLLs somewhere on your LIBPATH, or otherwise you'll spend days figuring out why XWorkplace is simply not working any more. (I had this once after a reinstall of OS/2, after which the DLLs where gone.) That is, XWorkplace classes will not load at Desktop startup, because the PMPRINTF DLL imports cannot be resolved. Neither will registering XWorkplace classes succeed. And don't expect to get an error message other than FALSE.

   By contrast, if XWP_DEBUG is not defined, release code is produced.

6. Replacing in-use files. You can rebuild XWorkplace even while the WPS is up and XWorkplace is installed. The makefiles will automatically unlock DLLs which are currently in use (DosReplaceModule). To do this, simply set XWP_UNLOCK_MODULES=YES. After the rebuild, restart the WPS to make it use the newly built DLLs.

   Note: Do not set this if you are using Warp 4 FP13 or FP14 because unlocking WPS modules will hang the WPS after the next Desktop restart. This problem has been fixed in FP15 and the Convenience Packs, so setting this variable to YES should be safe.

   The exception to this are XWPDAEMN.EXE and XWPHOOK.DLL, which are never unlocked. This is intentional. Unlocking an executable which has registered a system hook (which becomes part of every PM process on the system) will never release the hook DLL again, so you'd have to reboot to use the new DLL.

   Warning: If you don't restart the daemon before restarting the WPS, the XWorkplace startup folder will get processed again after the Desktop restart. To start XWPDAEMN.EXE explicitly, give it the "-D" option, or it will only tell you to get lost.

   So if you get an error during the build process which says "XWPDAEMN.EXE is in use", kill XWPDAEMN.EXE using some process killer, which will properly unload the hooks, and try building again.