The default installation will build Xew, demo and X Print Server (Xp) using the defaults of your system. It will automaticly include support for JPEG, TIFF and RLE, if it can find the libraries. The default will not use MOTIF subclassing.
Retrieve the packages
Unpack Xew-4.0.tar.gz and Xew-4.0-Xp.tar.gz in your chosen directory. Each of the packages will unpack into directory "./Xew-4.0/" and will create one or more subdirectories under it.
zcat package.tar.gz | tar xvf -
Xew-4.0 comes with GNU autoconf generated ./configure script. After
unpacking, the simplest configure and installation steps are
or
./configure --with-motif
'make test' attempts to run 'demo/texted' and X print server (Xp/pserver), if compiled. You need X Window DISPLAY to run the test.
If you want to install Xew into your system directories (root
required usually), you need to
If this simple installation did not give the result and features you require, you need to read more of this document and rerun the configure with additional switches.
./configure --help
Xew widgets can optionally be compiled as subclassed from the Motif XmManager. This configuration parameter enables the Motif subclassing. The C compiler options are optional and can be used to specify non-standard paths for the Motif includes (-I..) and library (-L..). This switch adds
-DUSING_MOTIF_122
The default is to compile Xew without MOTIF.
You need to use above flags if the default configuration did not find the libraries (--with), or it did find some, and you do not want to include them (--without).
The use of JPEG, TIFF or RLE packages requires that the following files exist
/usr/local/include/jpeglib.h
/usr/local/include/jerror.h
/usr/local/include/jconfig.h
/usr/local/include/jmorecfg.h
/usr/local/lib/libjpeg.a
/usr/local/include/tiff.h
/usr/local/include/tiffio.h
/usr/local/lib/libtiff.a
/usr/local/include/rle.h
/usr/local/include/rle_code.h
/usr/local/include/rle_config.h
/usr/local/include/rle_raw.h
If your includes and libraries were already in /usr/local/include and /usr/local/lib, then the default configure should already have found them. If your common shared includes are in some different place, you can override /usr/local assumption with
--with-local="-I<your-include-path> -L<your-library-path>"
If TIFF, JPEG or RLE libraries are installed into non-standard places, you can also specify indivially for each of them
--with-jpeg="-I<jpeg-include-path> -L<jpeg-library-path>"
--with-tiff="-I<tiff-include-path> -L<tiff-library-path>"
--with-rle="-I<rle-include-path> -L<tiff-library-path>"
Additionally, if any of the libraries have non-standard name (other than 'jpeg', 'tiff' or 'rle'), you can also add "-l<library-name>".
The template Imakefiles (Imakefile.in) will usually build all libraries (normal, shared, debugger and profiled) which Imake environment indicates being possible. Unfortunately, it quite often happens that regardless of the apparent support, the actual library templates are not working correctly in many installations. For this reason, the configure script will by default override the Imakefile and force only the NormalLib to be built.
By specifying a plain --with-dolibs
you can restore the default Imakefile build (configure will not
override anything). Or, you can individually enable or disable
specific library builds. For example
--with-dolibs="-shared" will disable
shared library build, but uses the defaults for others.
--with-dolibs=shared will not
magically produce shared libraries, if the system and imake
environment does not support them.
You can only specify either one of these or none.
-DUSING_PRINTSERVER is added to the compile
flags.
XSetPrintParams). The definition
-DUSING_PRINTSERVER is added to the compile flags.
-DUSING_XPRINTER is added
to the compile flags.
Athena (Xaw) and Xmu libraries and includes are usually included in the normal X environment, but if you have them installed in a non-standard place, which is not already covered by other configurations (such as --with-local), then you can add the necessary compiler options with these switches.
The build of ./Xew does not use or need Athena, but it does need some Xmu include files.
By default the configure script assumes that the ./demo and other possible application directories will be using the Xew buing built in the current directory.
The switch allows you to override this assumption. A simple
--with-xew (without any arguments) will
just override, and force the application to use the installed Xew from
the standard location. Use specific compiler options (-L, -I, -l) to
use non-standard locations.
This switch does not affect the ./Xew build process.
By default the configure script assumes the support for MIT Shared
Memory can be compiled into Xew, if the header <sys/shm.h>
exists, and adds -DSH_MEM into compile options in that
case.
Specifying --without-shmem will
prevent this test and does not specify any compile options. This is
useful, if you have the header tested by the default configuration,
but get compilation problems due to this.
Specifying --with-shmem sets
-DSH_MEM explicitly without testing anything (not very
useful).
Will override CDEBUGFLAGS in demo/Imakefile (and other application
files). Normal default for CDEBUGFLAGS is taken from Imake
DefaultCDebugFlags. This switch does not affect ./Xew
building.
--with-debug
DebuggableCDebugFlags.
--without-debug
OptimizedCDebugFlags (this is
what the DefaultCDebugFlags is set to usually, normally
you don't need to use this).
--with-debug="options"
-DIM_XCIN May work as a last ditch solution, if your C compiler and installed Imake environment do not match (typical with "out of box Solaris", which comes configured to use the Sun cc, but which is not present unless you bought it)
Examples
./configure --with-cc=gcc --with-cdebugflags="-O -Wall" ./configure --with-cc="cc -Aa -D_HPUX_SOURCE" --with-cdebugflags=-O
If the ./configure script fails, all hope is not lost yet. You can still
Imakefile.in in each subdirectory into
Imakefile, and use it as is, or after manually editing it
to fit your needs. Imakefile.in's are written for minimal
requirements and defaults.
./configure with closest approximation
of switches you can find, then edit the generated
Imakefile's.
In both cases, after editing the Imakefiles, you
proceed in each subdirectory as with any X package that comes with
Imakefile
If you try to compile this under X11R4 you may have to manually tweak the Imakefiles. At least Apollo sr10.2/R4 had two problems:
Because out of box Solaris configuration does not include a C
compiler, but the Openwin Imake configuration will, however, assume
that the Sun C compiler is used, the resulting Imakefiles from
configure are not very useful, even if you have Gnu C installed (and
configure finds it). To get things work, you must
change the Imake environment to use GCC (site.def), or try to
patch things using the --with-cc and
--with-cdebugflags override switches, for example
If above is not enough, you need to do some further hacking by editing the produced Imakefiles, or even Makefiles.
One of the nastiest things you may run into, is the situation where you already have one of the libraries (Xew or Xp) installed on your system directories, but want to use the new version in the build directory. The situation is nasty, because you may spend a lot of time trying to figure out why things work differently than you expect, without realizing that you are still using some old library. Beware!
In some Imake configurations (X11R6), there exists a make symbol
LDPRELIB, which is set to the default X11 library path,
and which in linking command prefixes all other libraries. The
./configure script attempts to nullify this, by exlicitly
setting this to empty, if Xew or Xp in build directory is to be used.
With Sun openwin (and X11R5?) Imake environment there is no such symbol, but the system library is explicitly inserted after the link options. In such case you need to edit the Makefile manually before running 'make' again: find the LDOPTIONS setting and remove the "-L$(USRLIBDIR)" from the end of the definition.
Unfortunaly, this only solves half of the problem in shared
library environments (such as SunOS, Solaris). When you run
applications, it will still use the system version of the libraries,
unless you change the LD_LIBRARY_PATH
(on Suns) to have the new library location searched before the system
libraries.