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.
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
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.
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:
XWPRUNNING
to the same directory which you
specified as the target path to WarpIN.
XWPRUNNING
to start.
This must point to the parent directory of bin\
, help\
etc.
in the XFolder/XWorkplace installation tree.
Example: SET XWPRUNNING=J:\Tools\XWorkplace
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.
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.