source: trunk/README.OS2@ 576

This is Qt version 4.5.1 GA for OS/2 and eCS.

This document contains a brief information on the OS/2 version of the Qt
library. Please read it carefully before starting your work. You may also
visit the project page at

  http://svn.netlabs.org/qt4/wiki

to get more information and the latest news and also to report bugs.

To get a brief list of OS/2-specific changes from release to release
please see the CHANGES.OS2 file included in this distribution.



REQUIREMENTS

In order to compile the Qt library and Qt-based applications, you will need
the following tools:

  - One of the OS/2 Warp 4, OS/2 Warp 4.5 or eComStation operating systems.

  - InnoTek GCC compiler version 3.3.5 CSD3 or 4.4.2 (recommended).
    You can download the GCC 4.4.2 compiler using the following link:

      http://download.smedley.info/gcc-4.4.2-os2-20091205.zip

    GCC 4.4.2 requires newer binutils available at:

      http://download.smedley.info/binutils-2.19.1-os2-20090427.zip

    Note that in order to use the above version of GCC, you will also need
    to install the previous 3.x version (e.g. 3.3.5 CSD3) available at:

      ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-csd3.zip

  - Patched OpenWatcom linker which you can download from here:

      ftp://ftp.netlabs.org/pub/gcc/wl-hll-r1.zip

    Note that if you use IBM ILINK (no matter what version), you will
    not be able to build the debug version of the library due to
    bugs/limitations of ILINK.

  - GNU Make 3.81beta1 or above (not tested) available at:

      http://unix.os2site.com/pub/binary/make/make-3_81beta1-bin-static.zip

  - eCUPS 1.3.11 or later to support printing in Qt. The eCUPS WPI is available
    at:

      ftp://ftp.netlabs.org/incoming/eCUPS003.wpi   or
      ftp://ftp.netlabs.org/pub/ecups/eCUPS003.wpi

    Linking against eCUPS also requires pthread.lib:

      http://web.os2power.com/download/lib/pthread-20100217-os2.zip

  - LxLite 1.3.3 or above (not tested) if you want Qt DLLs and application
    executables to be compressed (to save hard disk space and load time). If
    you have a recent eComStation installation (e.g. 2.0 rc6) you will already
    have LxLite installed. Otherwise, you may take it from here:

      http://www.os2site.com/sw/util/archiver/lxlt133.zip



SETTING UP THE ENVIRONMENT

After unpacking the GCC archive, you will have to set up the compiler
environment by invoking gccenv.cmd from the "bin" subdirectory with the correct
arguments (type gccenv.cmd -? for help). For the OpenWatcom linker, specify
WLINK as the second argument.

Please note that setting up the GCC 4.x environment requires some additional
steps. Please look through the README files contained within the OS/2
distribution.

You will also need to perform the following steps:

  - Make sure the selected linker, the make utility and LxLite executable are
    in PATH.

  - Make sure CMD.EXE is your command line processor (the generated makefiles
    will rely on its 'copy', 'if' and other commands). If you have a Unix shell
    (SH.EXE) in your environment, you may need to force GNU make to use CMD.EXE
    by doing 'set MAKESHELL=C:\OS2\CMD.EXE' where C: is your boot drive.

  - Do set LIBRARY_PATH=C:\OS2\DLL;C:\MPTN\DLL where C: is your boot drive.

  - Make sure that there are no traces of any other Watcom or OpenWatcom
    installation in the environment where you build Qt as it will most likely
    interfere with the patched OpenWatcom linker we use. This basically means
    removing all *WATCOM* environment variables and removing references to those
    Watcom installations from PATH.

  - Add the "bin" subdirectory of the directory where you unpacked the Qt4
    source tree to PATH and BEGINLIBPATH using its full path, e.g.:

      set PATH=D:\Coding\Qt4\bin;%PATH%
      set BEGINLIBPATH=D:\Coding\Qt4\bin;%BEGINLIBPATH%

  - Install the eCUPS WPI archive to enable printing support. If this WPI is
    installed, the Qt build system will pick up all necessary libraries
    automatically. Otherwise, you will need to use the following environment
    variables to tell it where to look for CUPS:

      set CUPS_INCLUDEPATH=X:\Path\to\CUPS\include
      set CUPS_LIBS=X:\Path\to\CUPS\lib\libcups.a

    Note that if the eCUPS WPI is not installed and these variables are not set,
    printing support will be completely disabled in the resulting Qt build.

    You will also need to make sure that pthread.lib is placed somewhere in your
    system library path so that the compiler can find it.

Note that the QTDIR environment variable used by previous Qt versions is not
used by Qt4 anymore (except two rare cases that do not affect the OS/2 platform
anyway and are probably leftovers after the migration of the qmake feature
specifications to Qt4). Therefore, there is no need to set this variable
explicitly. See also a note below about hard-coded paths to the source tree.

There is also no need to set the QMAKESPEC variable explicitly. If it is absent,
qmake will use the specification stored in the <Qt4_Home>/mkspecs/default
directory, which on OS/2 always refers to the "os2-g++" specification, the only
one supported at the present time.



COMPILING QT

You should skip this section if you downloaded and installed a binary
distribution of the Qt library for developers (qt-dev-X_Y_Z.wpi) and proceed
directly to section USING OFFICIAL BINARY QT PACKAGES below.

When the environment is set up, go to the directory where you unpacked the
Qt4 source tree and type:

  configure.cmd

This will set up the library (by creating necessary configuration and include
files and a bunch of Makefiles for variuos components) and build the qmake
utility.

The next step is to type:

  make

This will compile and link the library. Note that by default both the release
and the debug version of the library are built (please be patient, it may take
quite some time depending on your hardware). The release and debug libraries can
co-exist in the same source tree and may be used in parallel: all the debug DLLs
get a 'd' letter in their name preceeding the Qt major version number and use
separate directories for object files.

To save time, you may also build the release and the debug versions of the
library separately by typing 'make release' or 'make debug' accordingly
instead of just 'make'.

Once the library is successfully built, you may try to compile the demos
and examples by visiting the individual example subdirectories in the source
tree and typing 'qmake' followed by one of 'make', 'make release' or
'make debug' in that subdirectory.

NOTE:

     This version of Qt for OS/2 includes the Extended system tray plugin for
     XCenter/eCenter which is necessary to enable Qt support for the special
     notification area on the XCenter/eCenter panel (called the "system tray")
     which is used by many long-running applications to display their status.
     In order to activate this support, you need to install this plugin to your
     XCenter or eCenter. The plugin is built during the normal Qt build process
     and can be found in the file \plugins\xcenter\xsystray.dll in the Qt source
     tree. In order to install the plugin, do the following:

     a. Copy xsystray.dll to <XWorkplace installation folder>\plugins\xcenter\
        (on eComStation, this will be C:\ecs\system\ewps\plugins\xcenter\ where
        C: is your boot drive).

     b. Restart WPS.

     c. Add the "Extended system tray" widget to the XCenter/eCenter panel using
        the XCenter context menu ('Create new widget').

     Note that if you upgrade from the previous version of the plugin then
     please unlock xsystray.dll in the target folder using the UNLOCK.EXE
     utility (which you can find in the LxLite package, for example) before
     performing step a., otherwise the copy operation will fail.

IMPORTANT NOTE:

     Please take into account that the Qt library you build on your own as
     described above is NOT intended for wide distribution with Qt applications
     you port or create. Such private Qt builds help you develop Qt applications
     (because you can easily debug your program and parts of the Qt framework at
     the source level) but being widely distributed they will create a so-called
     DLL hell when a program running on a user computer crashes because it picks
     up a wrong build of the Qt library. This will happen because even a single
     change to Qt configuration options may make your build binary incompatible
     with another build. And even if you convince the user to isolate different
     DLLs (using BEGINLIBPATH and alike) it will create another major problem:
     two different Qt applications will load two different Qt builds into memory
     which will double resource usage; having three different builds will
     tripple it and so on -- what a vaste of system resources!

     In order to nicely solve this problem, netlabs.org provides the official
     binary builds of the Qt library distributed as WPI packages which are
     described in the next section.



USING OFFICIAL BINARY QT PACKAGES

For your convenience, netlabs.org provides the following binary distributions
of the Qt library (where X_Y_Z is the Qt version number):

  qt-lib-X_Y_Z.wpi   - Runtime DLLs and binaries ("lib" package)
  qt-dev-X_Y_Z.wpi   - Development libraries, tools and headers ("dev" package)

These packages are called the official binary packages of the Qt library for
OS/2. An official binary distribution is the most complete Qt build available
that enables all Qt library features and includes all standard Qt plugins that
were implemented for OS/2.

The "lib" package contains the release versions of DLLs (and may contain a few
helper binaries) necessary to run applications created using the Qt framework.
This package is usually installed by end users together with the Qt applications
they want to use.

The "dev" package contains pre-built release versions of import libraries and
a complete set of C++ include headers of the Qt framework. This package is used
by developers and porters of Qt applications to build release versions of the
applications for OS/2 that are binary compatibie with the "lib" package
described above.

Using the "dev" package requires the same environment as the one necessary for
building Qt and described in section SETTING UP THE ENVIRONMET above with the
exception that the "bin" subdirectory of the directory where you installed the
"dev" package needs to be added to PATH instead of the "bin" subdirectory of
the Qt4 source tree.

The process of compiling Qt applications using the "dev" package is basically
the same as with the hand made-build of Qt. Note, however, that if you are
developing or porting a Qt application, it is still recommended that you build
the debug version of the Qt library yourself and use it in your daily work since
it will give you much more feedback than the stripped down release version
contained in the "dev" package. The "dev" package, as said above, is intended
for making the final release build of the application for subsequent
distribution together with the official "lib" package.

Besides the "lib" and the "dev" packages, the following official packages exist
that you may also find useful:

  qt-examples-X_Y_Z.wpi  - Demo and example sources ("examples")