-and several Windows compilers to use precompilation (those tested are Microsoft Visual C++, Borland C++
-and Watcom C++).
-
-Borland precompilation is largely automatic. Visual C++ requires specification of {\tt "wx\_prec.h"} as
-the file to use for precompilation. Watcom C++ is automatic apart from the specification of
-the .pch file. Watcom C++ is strange in requiring the precompiled header to be used only for
-object files compiled in the same directory as that in which the precompiled header was created.
-Therefore, the wxWindows Watcom C++ makefiles go through hoops deleting and recreating
-a single precompiled header file for each module, thus preventing an accumulation of many
-multi-megabyte .pch files.
-
-\section{Libraries}
-
-Under UNIX, use the library libwx\_motif.a
-(Motif). Under Windows, use the library wx.lib for stand-alone Windows
-applications, or wxdll.lib for creating DLLs.
-
-\section{Configuration}
-
-The following lists the options configurable in the file
-\rtfsp{\tt include/base/wx\_setup.h.} Some settings are a matter
-of taste, some help with platform-specific problems, and
-others can be set to minimize the size of the library.
-
-\subsection{General features}
-
-\begin{twocollist}\itemsep=0pt
-\twocolitem{USE\_CLIPBOARD}{If 1, clipboard code is compiled (Windows only).}
-\twocolitem{USE\_CONSTRAINTS}{If 1, the constaint-based window layout system is compiled.}
-\twocolitem{USE\_DOC\_VIEW\_ARCHITECTURE}{If 1, wxDocument, wxView and related classes are compiled.}
-\twocolitem{USE\_DYNAMIC\_CLASSES}{If 1, the run-time class macros and classes are compiled. Recommended,
-and necessary for the document/view framework.}
-\twocolitem{USE\_EXTENDED\_STATICS}{If 1, wxStaticItem code is compiled for enhanced panel decorative items.
-Not rigorously tested, and not documented.}
-\twocolitem{USE\_HELP}{If 1, interface to help system is compiled.}
-\twocolitem{USE\_GAUGE}{If 1, the wxGauge class compiled.}
-\twocolitem{USE\_GLOBAL\_MEMORY\_OPERATORS}{If 1, redefines global new and delete operators to be compatible
-with the extended arguments of the debugging wxObject new and delete operators. If this causes problems
-for your compiler, set to 0.}
-\twocolitem{USE\_GNU\_WXSTRING}{If 1, the enhanced GNU wxString and regular expression class are compiled
-in place of the normal wxString class. See contrib/wxstring for details.}
-\twocolitem{USE\_IMAGE\_LOADING\_IN\_MSW}{Use code to allow dynamic .BMP loading
-under MS Windows.}
-\twocolitem{USE\_IMAGE\_LOADING\_IN\_X}{Use code in utils/image to allow dynamic .BMP/.GIF loading
-under X.}
-\twocolitem{USE\_RESOURCE\_LOADING\_IN\_MSW}{Use code to allow dynamic .ICO/.CUR loading
-under MS Windows.}
-\twocolitem{USE\_IPC}{If 1, interprocess communication code is compiled.}
-\twocolitem{USE\_MEMORY\_TRACING}{If 1, enables debugging versions of wxObject::new and wxObject::delete
-if the value of DEBUG is defined to more than 0.}
-\twocolitem{USE\_METAFILE}{If 1, Windows Metafile code is compiled.}
-\twocolitem{USE\_PANEL\_IN\_PANEL}{If 1, experimental panel-in-panel code is used
-for common dialog boxes. Not recommended, since tab traversal can suffer.}
-\twocolitem{USE\_POSTSCRIPT}{If 1, PostScript code is compiled.}
-\twocolitem{USE\_POSTSCRIPT\_ARCHITECTURE\_IN\_MSW}{Set to 1 to enable the printing architecture
-to make use of either native Windows printing facilities, or the wxPostScriptDC class depending
-on the wxApp::SetPrintMode setting.}
-\twocolitem{USE\_PRINTING\_ARCHITECTURE}{If 1, wxPrinter, wxPrintout and related classes are compiled
-for the print/preview framework.}
-\twocolitem{USE\_RESOURCES}{If 1, win.ini or .Xdefaults-style resource read/write code is compiled.}
-\twocolitem{USE\_SCROLLBAR}{If 1, wxScrollBar class is compiled. Not rigorously tested, and not documented.}
-\twocolitem{USE\_SPLINES}{If 1, spline code is compiled.}
-\twocolitem{USE\_TOOLBAR}{If 1, the wxToolBar class is compiled.}
-\twocolitem{USE\_TYPEDEFS}{If 1, a typedef will be used for wxPoint instead of
-a class declaration, to reduce overhead and avoid a Microsoft C++ memory bug.}
-\twocolitem{USE\_VLBOX}{If 1, wxVirtListBox code is compiled for a virtual listbox item.
-Not rigorously tested, and not documented.}
-\twocolitem{USE\_WX\_RESOURCES}{If 1, wxWindows resource file (.WXR) code is compiled.}
-\twocolitem{USE\_XFIG\_SPLINE\_CODE}{If 1, XFig-derived code is used for spline
-drawing. If 0, AIAI code is used, which is slower.}
-\twocolitem{USE\_XPM\_IN\_X}{If 1, XPM (colour pixmap) facilities will be compiled and used
-in wxBitmap under X.}
-\twocolitem{USE\_XPM\_IN\_MSW}{If 1, XPM (colour pixmap) facilities will be compiled and used
-in wxBitmap under MS Windows.}
-\end{twocollist}
-
-\subsection{X features}
-
-\begin{twocollist}
-\twocolitem{DEFAULT\_FILE\_SELECTOR\_SIZE}{Let Motif choose the size of
-XmFileSelectionBox. Otherwise, size is 500x600.}
-\twocolitem{PIXEL0\_DISABLE}{Define to disallow allocation of pixel 0 (wxXOR problem).}
-\twocolitem{USE\_GADGETS}{Use gadgets where possible rather than Widgets for items.
-Default is to use Gadgets.}
-\twocolitem{USE\_BUTTON\_GADGET}{Use gadgets for buttons. This can intefere with
-default button selection, so the default is zero.}
-\end{twocollist}
-
-\subsection{Windows and NT features}
-
-\begin{twocollist}
-\twocolitem{CTL3D}{CTL3D should only be used for 16-bit Windows programs.
-On Windows 95 and NT, native 3D effects are used. If you want to
-use it and don't already have CTL3D installed, copy the files in
-contrib/ctl3d to appropriate places (ctl3dv2.lib/ctl3d32.lib into your compiler lib
-directory, ctl3d.h into an include directory, and ctl3dv2.dll into
-windows/system). You may need to find a compiler-specific version of ctl3dv2.lib
-or ctl3d32.lib. Define CTL3D to be 1 in wx\_setup.h and link your executables with ctl3dv2.lib
-or ctl3d32.lib.}
-\twocolitem{USE\_ITSY\_BITSY}{If 1, compiles in code to support tiny window titlebars.}
-\twocolitem{USE\_ODBC}{If 1, compiles wxDatabase and wxRecordSet classes for ODBC
-access. Requires sql.h, sqlext.h files if set to 1 (see topic on database support).}
-\end{twocollist}
-
-\section{Makefiles}
-
-At the moment there is no attempt to make UNIX makefiles and
-PC makefiles compatible, i.e. one makefile is required for
-each environment.
-
-Sample makefiles for UNIX (suffix .UNX), MS C++ (suffix .DOS and .NT), Borland
-C++ (.BCC) and Symantec C++ (.SC) are included for the library, demos
-and utilities. The NT, Borland and Symantec makefiles cannot be
-guaranteed to be up-to-date since the author does not have
-these compilers.
-
-The controlling makefile for wxWindows is in the platform-specific
-directory, such as {\tt src/msw} or {\tt src/x}. This makefile will
-recursively execute the makefile in {\tt src/base}.
-
-\subsection{Windows makefiles}
-
-For Microsoft C++, normally it is only necessary to type {\tt nmake -f
-makefile.dos} (or an alias or batch file which does this). By default,
-binaries are made with debugging information, and no optimization. Use
-FINAL=1 on the command line to remove debugging information (this only
-really necessary at the link stage), and DLL=1 to make a DLL version of
-the library, if building a library.
-
-\subsection{UNIX makefiles}
-
-TODO.
-
-Debugging information is included by default; you may add DEBUG= as an
-argument to make to compile without it, or use the UNIX {\bf strip}
-command to remove debugging information from an executable.
-
-\normalbox{{\it Important note:} Most compiler flags are kept centrally in
-src/make.env, which is included by all other makefiles. This is the
-file to edit to tailor wxWindows compilation to your environment.}
-
-\section{Windows-specific files}
-
-wxWindows application compilation under MS Windows requires at least two
-extra files, resource and module definition files.
+and several Windows compilers to use precompilation which is largely automatic for
+compilers with necessary support. Currently it is used for Visual C++ (including
+embedded Visual C++), Borland C++, Open Watcom C++, Digital Mars C++
+and newer versions of GCC.
+Some compilers might need extra work from the application developer to set the
+build environment up as necessary for the support.
+
+\section{Libraries}\label{libraries}
+
+Most ports of wxWidgets can create either a static library or a shared
+library. wxWidgets can also be built in multilib and monolithic variants.
+See the \helpref{libraries list}{librarieslist} for more
+information on these.
+
+\section{Configuration}\label{configuration}
+
+When using project files and makefiles directly to build wxWidgets,
+options are configurable in the file
+\rtfsp{\tt "wx/XXX/setup.h"} where XXX is the required platform (such as msw, motif, gtk, mac). Some
+settings are a matter of taste, some help with platform-specific problems, and
+others can be set to minimize the size of the library. Please see the setup.h file
+and {\tt install.txt} files for details on configuration.
+
+When using the 'configure' script to configure wxWidgets (on Unix and other platforms where
+configure is available), the corresponding setup.h files are generated automatically
+along with suitable makefiles. When using the RPM packages
+for installing wxWidgets on Linux, a correct setup.h is shipped in the package and
+this must not be changed.
+
+\section{Makefiles}\label{makefiles}
+
+On Microsoft Windows, wxWidgets has a different set of makefiles for each
+compiler, because each compiler's 'make' tool is slightly different.
+Popular Windows compilers that we cater for, and the corresponding makefile
+extensions, include: Microsoft Visual C++ (.vc), Borland C++ (.bcc),
+OpenWatcom C++ (.wat) and MinGW/Cygwin (.gcc). Makefiles are provided
+for the wxWidgets library itself, samples, demos, and utilities.
+
+On Linux, Mac and OS/2, you use the 'configure' command to
+generate the necessary makefiles. You should also use this method when
+building with MinGW/Cygwin on Windows.
+
+We also provide project files for some compilers, such as
+Microsoft VC++. However, we recommend using makefiles
+to build the wxWidgets library itself, because makefiles
+can be more powerful and less manual intervention is required.
+
+On Windows using a compiler other than MinGW/Cygwin, you would
+build the wxWidgets library from the build/msw directory
+which contains the relevant makefiles.
+
+On Windows using MinGW/Cygwin, and on Unix, MacOS X and OS/2, you invoke
+'configure' (found in the top-level of the wxWidgets source hierarchy),
+from within a suitable empty directory for containing makefiles, object files and
+libraries.
+
+For details on using makefiles, configure, and project files,
+please see docs/xxx/install.txt in your distribution, where
+xxx is the platform of interest, such as msw, gtk, x11, mac.
+
+\section{Windows-specific files}\label{windowsfiles}
+
+wxWidgets application compilation under MS Windows requires at least one
+extra file: a resource file.
projects / wxWidgets.git / blobdiff