development release and OS/2 is considered to be in beta.
IMPORTANT NOTE: If you experience problems installing, please
development release and OS/2 is considered to be in beta.
IMPORTANT NOTE: If you experience problems installing, please
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
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
- samples;
- documentation in HTML Help format;
- makefiles for VisualAge V3.0 (possibly for EMX and Watcom C++);
- samples;
- documentation in HTML Help format;
- makefiles for VisualAge V3.0 (possibly for EMX and Watcom C++);
-All but the documentation is included in wxOS2-2.5.1.zip, documentation
-must be downloaded separately from the wxWindows Web site.
+All but the documentation is included in wxOS2-2.6.0.zip, documentation
+must be downloaded separately from the wxWidgets Web site.
- mmedia.zip. Audio, CD, video access for Windows and Linux.
- ogl3.zip. Object Graphics Library: build network diagrams, CASE tools etc.
- mmedia.zip. Audio, CD, video access for Windows and Linux.
- ogl3.zip. Object Graphics Library: build network diagrams, CASE tools etc.
-x:\wx\wxWindows-2.5.1\docs (your HTML reference manual)
-x:\wx\wxWindows-2.5.1\include\wx
-x:\wx\wxWindows-2.5.1\include\wx\generic
-x:\wx\wxWindows-2.5.1\include\wx\html
-x:\wx\wxWindows-2.5.1\include\wx\os2
-x:\wx\wxWindows-2.5.1\samples\.... (all the sample directories)
-x:\wx\wxWindows-2.5.1\src
-x:\wx\wxWindows-2.5.1\src\common
-x:\wx\wxWindows-2.5.1\src\generic
-x:\wx\wxWindows-2.5.1\src\html
-x:\wx\wxWindows-2.5.1\src\jpeg
-x:\wx\wxWindows-2.5.1\src\os2
-x:\wx\wxWindows-2.5.1\src\png
-x:\wx\wxWindows-2.5.1\src\tiff
-x:\wx\wxWindows-2.5.1\src\zlib
+x:\wx\wxWidgets-2.6.0\docs (your HTML reference manual)
+x:\wx\wxWidgets-2.6.0\include\wx
+x:\wx\wxWidgets-2.6.0\include\wx\generic
+x:\wx\wxWidgets-2.6.0\include\wx\html
+x:\wx\wxWidgets-2.6.0\include\wx\os2
+x:\wx\wxWidgets-2.6.0\samples\.... (all the sample directories)
+x:\wx\wxWidgets-2.6.0\src
+x:\wx\wxWidgets-2.6.0\src\common
+x:\wx\wxWidgets-2.6.0\src\generic
+x:\wx\wxWidgets-2.6.0\src\html
+x:\wx\wxWidgets-2.6.0\src\jpeg
+x:\wx\wxWidgets-2.6.0\src\os2
+x:\wx\wxWidgets-2.6.0\src\png
+x:\wx\wxWidgets-2.6.0\src\tiff
+x:\wx\wxWidgets-2.6.0\src\zlib
--------------------------
In addition to VisualAge V3.0 Fixpack 8 you will need the following inorder
--------------------------
In addition to VisualAge V3.0 Fixpack 8 you will need the following inorder
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
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
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
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
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.
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.
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,
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,
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
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
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
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\wxWindows-2.5.1\build\pm. Now we need to set some environment
-variables, namely MAKE_SHELL (to a Unix like shell, let's assume ash)
+\wx\wxWidgets-2.6.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.
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.
-Be warned that depending on the precise version of your make, setting
-MAKE_SHELL might not be sufficient, it might be necessary to set SHELL
-and even COMSPEC to a unix like shell as well.
+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.
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
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
Calling `make' now should start a compile run which hopefully ends
with a library being placed in the lib subdirectory.
Calling `make' now should start a compile run which hopefully ends
with a library being placed in the lib subdirectory.
-Note however, that the auto-generated .d files (containing depency
-information) use a mixture of "/" and "\" path separators, that
-confuses many make versions. Therefore you'll often get error messages
-indicating that some file with a random character in place of a path
-separator cannot be found on subsequent calls to make. The only solution
-currently available for this requires "sed": Run
- for %1 in (*.d) do @(sed "s/\//\\/g" < %1 > dep.sed && copy dep.sed %1)
-under "cmd" in the build directory (or a suitable variant of it under a
-unix like shell). Note however, that a new call to make will generate
-new .d files, so you will likely have to run that between any two calls
-to make.
-
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
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
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
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
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
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
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.
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.
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
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
projects / wxWidgets.git / blobdiff