
                                    CONTENT
                                       
    1. Xew 4.0 default installation
    2. Tailored installation using configuration parameters
    3. Manual configuration
    4. X11R4 configuration
    5. Openwin and Solaris
    6. Installed library problems
       
                        XEW 4.0 DEFAULT INSTALLATION
                                       
   
   
   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
   Xew-4.0.tar.gz
       "Core" distribution (Xew and demo)
   Xew-4.0-Xp.tar.gz
       Prototype X Print Server implementation (Xp)
       
   
   
   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
    1. cd Xew-4.0
    2. ./configure
       or
       ./configure --with-motif
    3. make
    4. make test
       
   
   
   '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
    1. cd Xew
    2. make install
    3. make install.includes (if 'make install' did not do this)
       
              TAILORED INSTALLATION USING CONFIGURE PARAMETERS
                                       
   
   
   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.
   
   Use
          ./configure --help
          
   to find out about the supported switches in the configure script (this
   document may not always be quite up to date).
   
   Warning!
          The configure script is generated by GNU autoconf 2.7. This
          version still has the bug that causes problems, if you try to
          specify a library that has '-' in the name (thus, "-ljpeg-6" is
          not going to work).
          
--with-motif[="C compiler options"]

   
   
   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
          
   definition into Xew builds.
   
   The default is to compile Xew without MOTIF.
   
--with-local[="C compiler options"]
--with-jpeg[="C compiler options"]
--with-tiff[="C compiler options"]
--with-rle[="C compiler options"]
--without-local
--without-jpeg
--without-tiff
--without-rle

   
   
   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
   
   - from jpegsrc.v5 (or later)
          /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
          
   - from tiff-3.2beta.tar.Z (or later)
          /usr/local/include/tiff.h
          /usr/local/include/tiffio.h
          /usr/local/lib/libtiff.a
          
   - from utah raster toolkit
          /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>"
          
   The '--with-local' can be used with any number of -I and -L options.
   
   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>".
   
--with-dolibs[="[-]normal [-]debug [-]profiled [-]shared"]

   
   
   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.
   
   Note:
          Forcing a build of a library type that your environment does
          not support will not work, and will result compilation problems
          during the make. Thus --with-dolibs=shared will not magically
          produce shared libraries, if the system and imake environment
          does not support them.
          
--with-print[="C compiler options"]
--with-xprinter[="C compiler options"]

   
   
   You can only specify either one of these or none.
   
   Neither (the default)
          if the build directory has a subdirectory "./Xp", the configure
          assumes this directory contains the X Print Server library and
          client includes, that will be built along with the other
          things. The definition -DUSING_PRINTSERVER is added to the
          compile flags.
          
   --with-print
          if the X Print Server library is already installed in some
          other place. The configure will not test the existence of the
          ./Xp directory, but will test the existence of the library
          (with function XSetPrintParams). The definition
          -DUSING_PRINTSERVER is added to the compile flags.
          
   --with-xprinter
          if you are using the Xprinter printing library from Bristol
          Technology Inc. The definition -DUSING_XPRINTER is added to the
          compile flags.
          
--with-xmu[="C compiler options"]
--with-xaw[="C compiler options"]

   
   
   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.
   
--with-xew[="C compiler options"]

   
   
   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.
   
--without-shmem
--with-shmem

   
   
   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).
   
--with-debug[="C compiler options"]
--without-debug

   
   
   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
          sets CDEBUGFLAGS to DebuggableCDebugFlags.
          
   --without-debug
          sets CDEBUGFLAGS to OptimizedCDebugFlags (this is what the
          DefaultCDebugFlags is set to usually, normally you don't need
          to use this).
          
   --with-debug="options"
          sets CDEBUGFLAGS to the specified options string.
          
--with-im[="C compiler options"]

   The only special input method supported by Xew is BIG5 through
   something that is called "xcin" (the support for this was provided by
   You Shung-I <daniel@info1.csie.nctu.edu.tw>). Using this switch adds
   
          -DIM_XCIN
          
   definition into Xew builds. You will probably need to specify
   additional include and library paths.
   
--with-cc="cc command"
--with-cdebugflags="C compiler options"

   
   
   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

                            MANUAL CONFIGURATION
                                       
   
   
   If the ./configure script fails, all hope is not lost yet. You can
   still
    1. copy the 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.
    2. or, just run ./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
    1. cd subdirectoy
    2. xmkmf -a (or 'xmkmf; make includes; make depend')
    3. make
    4. make install (if applicable, to install libraries)
    5. make install.includes (if applicable, sometimes 'make install'
       already does this)
       
                             X11R4 CONFIGURATION
                                       
   
   
   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:
    1. 'make includes' tried to use 'mkdirhier.sh' instead of
       'mkdirhier'. Can do 'make install.includes' instead and use the
       installed includes or try uncommenting the MKDIRHIER definition in
       Imakefile].
    2. 'make install.includes' does not actually create the X11/Xew
       *directory*. Had to create the directory by hand. WATCH OUT FOR
       THIS! It creates a *file* X11/Xew!
       
   Note
          I do not have any X11R4 system available at this point. This
          release is not tested under X11R4.
          
                             OPENWIN AND SOLARIS
                                       
   
   
   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
   
          ./configure --with-cc=gcc --with-cdebugflags="-O -Wall"
          
   
   
   If above is not enough, you need to do some further hacking by editing
   the produced Imakefiles, or even Makefiles.
    1. you might need to define OPENWINHOME environment,
    2. 'make includes' fails. add line 'MKDIRHIER = mkdirhier' into
       Imakefile
       
                         INSTALLED LIBRARY PROBLEMS
                                       
   
   
   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.
     _________________________________________________________________
   
   
     1995 Markku Savela
