4c51a665c6
Applied patch by snowleopard2 fixing a bunch of typos such as misspellings and double words in the documentation. Combined the patch with some local queued typos waiting to be committed as well as adding new typo fixes inspired by the patch.
Function names with American spelling were not changed nor was third-party code touched. The only code changes involve some changes in strings that are translated ("Can not" -> "Cannot").
Closes #13063 (again).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67280 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
225 lines
11 KiB
Plaintext
225 lines
11 KiB
Plaintext
Installing wxWidgets
|
|
--------------------
|
|
|
|
This is wxWidgets for IBM OS/2 Warp3 and Warp4. This is an unstable
|
|
development release and OS/2 is considered to be in beta.
|
|
|
|
IMPORTANT NOTE: If you experience problems installing, please
|
|
re-read this instructions and other related files (changes.txt,
|
|
readme.txt, notes on the Web site) carefully before mailing
|
|
wx-users or the author. Preferably, try to fix the problem first and
|
|
then send a patch to the author. Please report bugs using the
|
|
bug report form on the wxWidgets web site.
|
|
|
|
Unarchiving
|
|
-----------
|
|
|
|
At this time there is no comprehensive setup.exe type installation program.
|
|
wxWidgets for OS/2 requires you download various .zip files and unpack them
|
|
to your desired location on your system. Pick a location say,
|
|
C:\wx\wxWidgets-2.8.0, copy the .zip files to there and unzip them ensuring you
|
|
unzip the subdirectories as well. You will need:
|
|
|
|
- All common, generic and OS2-specific wxWidgets source;
|
|
- samples;
|
|
- documentation in HTML Help format;
|
|
- makefiles for VisualAge V3.0 (possibly for EMX and Watcom C++);
|
|
- JPEG, TIFF, PNG, ZLIB, wxSTC, REGEX, EXPAT library sources.
|
|
|
|
All but the documentation is included in wxOS2-2.8.0.zip, documentation
|
|
must be downloaded separately from the wxWidgets Web site.
|
|
|
|
|
|
General installation notes
|
|
--------------------------
|
|
|
|
After unzipping everything your directory tree should look something like
|
|
this:
|
|
|
|
x:\wx\wxWidgets-2.8.0\docs (your HTML reference manual)
|
|
x:\wx\wxWidgets-2.8.0\include\wx
|
|
x:\wx\wxWidgets-2.8.0\include\wx\generic
|
|
x:\wx\wxWidgets-2.8.0\include\wx\html
|
|
x:\wx\wxWidgets-2.8.0\include\wx\os2
|
|
x:\wx\wxWidgets-2.8.0\samples\.... (all the sample directories)
|
|
x:\wx\wxWidgets-2.8.0\src
|
|
x:\wx\wxWidgets-2.8.0\src\common
|
|
x:\wx\wxWidgets-2.8.0\src\generic
|
|
x:\wx\wxWidgets-2.8.0\src\html
|
|
x:\wx\wxWidgets-2.8.0\src\jpeg
|
|
x:\wx\wxWidgets-2.8.0\src\os2
|
|
x:\wx\wxWidgets-2.8.0\src\png
|
|
x:\wx\wxWidgets-2.8.0\src\tiff
|
|
x:\wx\wxWidgets-2.8.0\src\zlib
|
|
|
|
If you are using VisualAge, you will also need to ensure you have a
|
|
\lib directory as well, x:\wx\wxWidgets-2.8.0\lib
|
|
and you will have to set a WXWIN environment variable in your
|
|
config.sys,
|
|
SET WXWIN=X:\WX\WXWINDOWS-2.8.0;
|
|
|
|
Compilation
|
|
-----------
|
|
|
|
For now, only VisualAge V3.0 FP 8 and EMX-0.9d (with fix4) are supported.
|
|
However, the library has been successfully compiled with Watcom C++ as
|
|
well. As those build environments get a bit more "formalized", I will add
|
|
them here.
|
|
|
|
Compilation with VisualAge on the one hand and EMX on the other hand are
|
|
rather different, VisualAge is essentially following Windows' way of doing
|
|
it, EMX is following the example of the unix ports.
|
|
|
|
Compilation with VisualAge
|
|
--------------------------
|
|
|
|
In addition to VisualAge V3.0 Fixpack 8 you will need the following in order
|
|
to successfully build and use wxWidgets for OS/2:
|
|
|
|
1. IBM OS/2 Toolkit Version 4.5 or later
|
|
2. IBM TCPIP V4.0 or later
|
|
3. You will need the IBMLAN Lan Requester service and UPM if you wish to use
|
|
network based components of the library (generally a standard part of any
|
|
Warp Connect 3.0 or Warp 4.0 installation.
|
|
4. I strongly suggest that you have the latest IBM fixpacks installed for
|
|
all your components.
|
|
|
|
Go to the \src directory and open the file, makeva.env (there should be a
|
|
.env for each supported compiler when they are fully supported), for edit.
|
|
This is where the "make" environment for wxOS2 is set. Locate UMPLIB, NETLIB,
|
|
and TCPIP environment variables about 20 lines down. Set these to match
|
|
your system.
|
|
|
|
There are number of possible outputs you can produce. There is a static
|
|
lib and a dynamically linked lib, and both can be built in debug or release
|
|
mode. Since wxOS2 is a beta and a rough one at that, I suggest, for now,
|
|
you stick to the debug builds. The resultant linkable binaries will be
|
|
output to the \lib directory as will the .dll files. The statically linked
|
|
lib will be named wx.lib. Each of the third party libs will be there as well,
|
|
including png.lib, jpeg.lib, tiff.lib, and zlib.lib. For DLL builds the
|
|
import libs will have the same name, only with a 'd' appended. Thus the
|
|
import library for the main lib in a dll build is wxd.lib.
|
|
|
|
Object modules will be output into paths dictated by the build mode. For
|
|
example, for debug static the outputs will be in DebugOS2, for DLLs in
|
|
DebugOS2DLL.
|
|
|
|
For your first build, you can directly build the library. For subsequent
|
|
builds you will want to "clean" the output paths. To build the static library
|
|
go to \src and execute nmake all -f makefile.va. To clean out the outputs
|
|
execute nmake clean -f makefile.va.
|
|
|
|
To build the wx.dll execut nmake all -f makefile.va WXMAKINGDLL=1. To clean
|
|
the outputs execute namek clean -f makefile.va WXMAKINGDLL=1. For
|
|
VisualAge 3.0 we use the module definition file method.
|
|
|
|
If, for some reason you encounter linking problems with your dll build you may
|
|
need to rebuild the module definition file, wx23.def, found in \src\os2. To
|
|
do this you need to have a static version built. Go to the \lib directoy and
|
|
execute CPPFILT /B /P wx.lib>temp.def. Copy this file to \src\os2. Delete
|
|
the temp.def from your \lib directory.
|
|
|
|
I find the following to be the easiest to reconstruct the .def file. Open
|
|
both the wx23.def and the temp.def file. Copy the header of the wx23.def to
|
|
the clipboard and paste it into the top of the temp.def file. If you have
|
|
a valid SQL database client with its SDK on your system you can skip the next
|
|
step. wxWidgets included some ODBC and SQL modules. They expect the standard
|
|
sql.h and such to available. If you do not have a database client with its
|
|
SDK (such as DB/2) then for the .dll build you need to delete the exports for
|
|
the following three modules from your temp.def file, db.cpp, dbgrid.cpp and
|
|
dbtable.cpp. save you changes to temp.def. Delete wx23.def and rename your
|
|
temp.def to wx23.def and you are ready to go.
|
|
|
|
I hope to clean up the .dll builds at some point before the library is
|
|
a full fledged production caliber product. Fortunately EMX and Watcom can use
|
|
the import and export pragmas successfully negating the need for manual .def
|
|
files. VA 3.0, unfortunately in C++ does not properly export the mangled
|
|
names so we are stuck with the CPPFILT .def file method of .dll builds for
|
|
now.
|
|
|
|
When building an application that uses the wx.dll you need to build it using
|
|
the WXUSINGDLL=1 macro. For example to build the minimal sample you would
|
|
go to \samples\minimal and execute nmake all -f makefile.va WXUSINGDLL=1.
|
|
|
|
I strongly suggest when developing apps using wxWidgets for OS/2 under old
|
|
VisualAge 3.0, that you use the dynamically linked library. The library is
|
|
very large and even the most trivial statically linked .exe can be very
|
|
large and take a long time to link. The release builds are much smaller,
|
|
however. Fortunately, EMX seems to build much smaller static executables.
|
|
|
|
Compilation using EMX
|
|
---------------------
|
|
|
|
In addition to EMX-0.9d you will need a rather complete Unix-like
|
|
environment, starting with a shell (e.g. ash) and most of the
|
|
GNU file/text/shell utilities, but also flex, bison, sed, grep, awk
|
|
and GNU make. Particularly note that uname is relevant to get the
|
|
configure script working - the one from GNU shell utilities 1.12
|
|
does work (check that uname -s returns "OS/2" and uname -m returns "i386"
|
|
and you should be mostly fine.
|
|
|
|
The first thing to do is to decide on a build directory. You can either
|
|
do in-tree builds or you can do the build in a directory separated from
|
|
the source directory. The later has the advantage, that it is much easier
|
|
to compile and maintain several ports of wxWidgets on OS/2 - if you are
|
|
developping cross-platform applications you might want to compile (and
|
|
update) e.g. wxGTK or wxX11 as well.
|
|
|
|
In the following, let's assume you decided to build in
|
|
\wx\wxWidgets-2.8.0\build\pm. Now we need to set some environment
|
|
variables, namely MAKESHELL (to a Unix like shell, let's assume ash)
|
|
and INSTALL (to point to the install script. If you omit this, configure
|
|
might find something like the system's tcpip\pcomos\install.exe which will
|
|
not do the thing you want), e.g.
|
|
SET MAKESHELL=ash
|
|
SET INSTALL=/wx/wxWidgets-2.8.0/install-sh -c
|
|
|
|
Be warned that depending on the precise version of your make, the
|
|
variable that needs to be set might be MAKE_SHELL instead of MAKESHELL.
|
|
If you have a really deficient version of GNU make, it might even be
|
|
necessary to set SHELL or even COMSPEC to a unix like shell as well.
|
|
|
|
Now run the provided configure script by executing e.g.
|
|
`ash -c "../../configure \
|
|
--prefix=directory_where_you_want_wxWidgets_to_be_installed"'
|
|
from within the build directory (the relative path might be different
|
|
depending on the build directory you selected).
|
|
If you are already running some unix-like shell and not cmd, you may
|
|
of course ommit the `ash -c' part in the above command.
|
|
This will create a whole directory structure containing lib and sample
|
|
directories which each essentially contain a suitable makefile.
|
|
|
|
Calling `make' now should start a compile run which hopefully ends
|
|
with a library being placed in the lib subdirectory.
|
|
|
|
Now you can change in the samples subdirectory and call make to compile
|
|
all samples, however currently not all will work on OS/2, so you might
|
|
prefer to change into the directory of a specific sample
|
|
(e.g. samples\minimal) and call make there to just build this one example.
|
|
Essentially, each sample that's not working indicates an area, where help
|
|
in porting wxWidgets to OS/2 would be appreciated.
|
|
|
|
Finally, you can run `make install' which should install wxWidgets to
|
|
the desired place.
|
|
Note that we also install the wx-config script which wants to help you
|
|
compiling your own applications, e.g. `wx-config --cxxflags` will emit the
|
|
flags that are needed for compiling source code which includes wxWidgets
|
|
headers, `wx-config --libs` will emit the flags needed for linking against
|
|
wxWidgets (wx-config is assuming you are calling it from a unix-like shell!).
|
|
|
|
For building a DLL, the only supported way currently is to first build the
|
|
static library and then use Andrew Zabolotny's dllar.cmd. However, this
|
|
works quite nicely.
|
|
|
|
Finally, if you also want to build a different port, e.g. wxGTK, you
|
|
essentially have to use the procedure described above, the only difference
|
|
being that you have to pass a switch to configure indicating which port
|
|
to build. If you do not do this in a separate build directory (e.g.
|
|
\wxWidgets-2.8.0\build\gtk), you'll have to do a `make clean' first.
|
|
The magical switches that have to be passed to configure for the various
|
|
ports are --with-gtk (wxGTK), --with-motif (wxMotif), --with-x11 (wxX11),
|
|
and --disable-gui (wxBase). Note that contrary to the native, PM based
|
|
OS/2 port, all of those ports work slightly better with POSIX/2's cExt
|
|
library. If include and library path include the suitable paths, -lcExt
|
|
is automatically appended to the linker flags by the configure script.
|