This section describes the build environment which is used by the makefiles.

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. 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:

  4. 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.

  5. 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). After the rebuild, restart the WPS to make it use the newly built DLLs. To do this, simply set XWP_UNLOCK_MODULES=YES.

    Note: This environment variable has was with V0.9.3 because with Warp 4 FP13, unlocking WPS modules hung the WPS after the next Desktop restart. This problem has been fixed with FP15, so there is really no reason to not have this variable set to YES any more.

    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 XWPDAEMON.EXE explicitly, give it the "-D" option, or it will tell only you to get lost.

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