Compiling software using the EW/WDS libraries is most easily done
using the included scripts.
Manual specification of options will also be described.
A MAKEME script can be put in the module's compile directory
which contains module specific information,
such as the names of source files and extra include files and libraries.
MAKEME calls G_MAKEME,
a general purpose script which identifies the platform and sets the defines
for the Coral Tree headers and selects the native libraries it will need.
G_MAKEME calls G_MAKE, a real makefile for the standard 'make'.
To use the libraries without using the scripts,
use must set the same defines and use the same libraries as the scripts would.
A quick way to discover these is to compile one of the test programs and read
what 'make' does.
We will describe our installation for our local users and
to clarify the organization.
Your installation may vary requiring different environment settings.
Our file '/home/symhost/sym/appl/coral/coralrc' contains
the following script setting environment variables:
# source me (csh/tcsh)
# Set environment variables for Coral Tree
if (${?GLOBALBASE} == "0") then
setenv GLOBALBASE /home/symhost/sym
endif
setenv CVSROOT ${GLOBALBASE}/proj/coral/cvs
setenv SCRIPT_BIN ${GLOBALBASE}/global/script
setenv PLATFORM `${SCRIPT_BIN}/platform`
setenv CORAL_APPL ${GLOBALBASE}/appl/coral/dev
setenv GLOBAL_BIN ${GLOBALBASE}/global/${PLATFORM}/bin
Note the executable 'platform' which gives a string unique to the platform type.
This file can be copied into your home directory and source from one
of your login scripts.
The compiles should work without these environment variable (using defaults)
as long as platform is in your path or ${PLATFORM} is set.
For us on an SGI, this script results in:
GLOBALBASE = /home/symhost/sym SCRIPT_BIN = /home/symhost/sym/global/script PLATFORM = mips_irix_6 CORAL_APPL = /home/symhost/sym/appl/coral/dev GLOBAL_BIN = /home/symhost/sym/global/mips_irix_6/bin
A different user may wish to specify 'stable' instead of 'dev' in ${CORAL_APPL}.
This should be enough to compile using the scripts.
The header meta/platform.h should contain a definition for each of the
following variables from the specified values.
You shouldn't need to change them.
OSD_OSTYPE=OSD_WIN32, OSD_UNIX OSD_OS=OSD_WINNT, OSD_IRIX, OSD_SUNOS, OSD_NECEWS, OSD_HPUX, OSD_LINUX, OSD_LYNX OSD_OSVER= (major version number, like 4) OSD_COMPILER=OSD_VISUAL, OSD_GNU, OSD_ANSI, OSD_KR OSD_HARDWARE=OSD_MIPS, OSD_SPARC, OSD_HPPA, OSD_X86, OSD_68K, OSD_AXP OSD_THREADS=OSD_WIN32_THREADS, OSD_SGI_SPROC, OSD_NO_THREADSEW has additional variables that can be defined.
EW_WL=EW_WIN32, EW_XWIN, EW_MEX EW_GL=EW_GDI, EW_X_GFX, EW_OPENGL, EW_IRISGLBy default, Win32 platforms use EW_WIN32/EW_GDI and other platforms use EW_XWIN/EW_X_GFX. Both Win32 and X platforms can compile using EW_OPENGL if the OpenGL software is installed. EW_MEX and EW_IRISGL modes are not current and are not likely to be updated.
The Coral Tree include files can be found using a compile flag:
-I${CORAL_APPL}/${PLATFORM}/include
which may resolve to something like:
-I/home/symhost/sym/appl/coral/dev/mips_irix_6/include
Similarly, the Coral Tree libraries can be found using a compile flag:
-I${CORAL_APPL}/${PLATFORM}/lib
which may resolve to something like:
-I/home/symhost/sym/appl/coral/dev/mips_irix_6/lib
The libraries, in prefered order, can be specified as:
-lwdsXX -lewXX -lwba -lgpl -losd
Note the postfix XX on -lwds and -lew indicates the XWIN/X_GFX version.
Other postfixes are used for other window/graphics configurations.
The remaining difficulty is to specify the required native libraries
for the specific platform, something the G_MAKEME script takes care of.
This can be done by copying the info from the making
of a test program or by reading through G_MAKEME.
The primary such lib is libX11.
Note that Xt and Motif are not used and not needed.
Some older Sun's appear to have a dependency from X11
into the extensions and can be resolved with:
-lX11 -lXext -lX11
The repetition seems to be necessary because of an interdependence
and a limitation of Sun's linker.
By default, the EW system uses/allocates 16 colors under the window system.
This is rarely a problem with 8-bit or better X terminals,
but some limited NT platforms appear to enter a 20-color fixed-pallete
mode at high resolutions.
We have chosen not to use dithering in order to maintain the integrity
of the details.
However, under this mode, this fixed palette will cause a noticeable
difference in a interface's color scheme.
We prefer not to change the system palette and cause system windows
to flash between color maps.
Suggestions are welcome.
Under X Windows when double-buffered,
if there is not sufficient space in the colormap,
the system will automatically degrade color resolution
from 16 to 8 to 4 colors.
Colormap allocation is done independently for single-buffer and
double-buffered windows.
Double-buffered windows require n*n colormap entries for n colors.
Under X Windows when single-buffered, an algorithm is used to share
other application's colormap indices.
First, the existing colors are searched for read-only reusable entries
that are within 5% error.
If no existing cell is close enough, colormap cells are allocated,
individual and not neccessarily sequentially.
If the colormap fills up, poor matches are used, up to 25% error.
Otherwise, one of the existing indexes is used,
either by remainder of 8 or remainder of 4.
If absolutely nothing else is valid, Black is used.
Under X Windows, there is a particular sequence that can prevent some windows
from opening properly. Assuming a common 8-bit colormap, a 16-color
double-buffered window will consume the entire colormap (16*16=256).
If an attempt is subsequently made to open a single-buffered window
(with any number of colors), it will fail after trying to degrade.
This will not fail if the single buffered window is opened first,
since the double-buffered window will see less than 256 free entries
and open with degraded color resolution.
Note that once a window of either single or double buffering is opened,
subsequent openings of windows of the same single/double buffering
can be made without consuming any more of the colormap.
Note also that EW will attempt to use the default visual and colormap,
if possible. If it cannot, some platform configurations will exhibit
colormap swapping. In this case, either the EW application OR the root
background system and remaining applications
(whichever is not in focus)
will use the inappropriate colormap,
potentially making them unreadable or even flash repeatedly.