wxWindows安装，新手必看，高手指教

summerbreeze

nstalling wxWidgets 2.6.0



Author : summerbreeze

Email:    summerbreeze@stu.xjtu.edu.cn

-----------------------------------------------------------

我把文件放在了

http://summer:summer@219.245.169.30/wxWindows/



找到了wxWorkshop 工具，还没找到好的GUI 设计器，大家推荐一个

wxWinWizard is VC6.0  wizard template,you need to compile it yourself!

Then copy the setup.h to $WXWIN/include/wx/(from $WXWIN/include/wx/msw/目录 )



却说缺少zlibd.lib,还没搞定！！zlib.lib已存在，
可能是wxzlib.lib  to zlib.lib 缺少影射,找了一个wxVC.h
不会用???


估计要把 nmake –f BUILD=debug



1.注意安装平台（支持XP）:



This is wxWidgets 2.6.0 for Microsoft Windows 9x/ME, Windows NT,

Windows 2000, Windows XP and Windows CE.



These installation notes can be found in docs/msw/install.txt     （note：我这里是删节版）

in your wxWidgets distribution.







2. Unarchiving(解压，未作任何实质性的工作)

============================================================



A setup program is provided (setup.exe) to automatically copy

files to a directory on your hard disk. Do not install into a

path that contains spaces.



Alternatively, you may unarchive the .zip form by hand:

wxMSW-x.y.z.zip where x.y.z is the version number.         (note: 你可以自己解压zip文件)





3 编译Compilation

===========



The following sections explain how to compile wxWidgets with each supported

compiler. Search for one of Microsoft/Borland/Watcom/Symantec/Metrowerks/

Cygwin/Mingw32 to quickly locate the instructions for your compiler.





All makefiles and project are located in build\msw directory.   （note 注意是在build\msw目录）







////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Note

：wx/setup.h 重要性：

Each lib\ subdirectory has wx subdirectory with setup.h as seen above.

This file is copied there from include\wx\msw\setup.h (and if it doesn't exist,

from include\wx\msw\setup0.h) and this is the copy of setup.h that is used by

all samples and should be used by your apps as well



你必须把他们放入你的程序的include/wx/ 目录；

Please note that the VC++ 6.0 project files will work for VC++ .NET also.



////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

These directories also contain subdirectory with wx/setup.h header. This

subdirectory is named after port, Unicode, wxUniv and debug settings and

you must add it to include paths when compiling your application. Some

examples:



  lib\vc_lib\msw\wx\setup.h          VC++ static, wxMSW

  lib\vc_lib\mswud\wx\setup.h        VC++ static, wxMSW, Unicode, debug

  lib\vc_lib\mswunivd\wx\setup.h     VC++ static, wxUniversal, debug



Below are compiler specific notes followed by customizing instructions that

apply to all compilers (search for "Configuring the build").







////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Microsoft Visual C++ compilation



1）到目录 build\msw\wx.dsw 让VC自己编译

如何控制Unicode/ANSI, Debug/Release and wxUniversal or native variations.

一定要修改build\msw\config.*对应的编译选项。

或者：build菜单中“set active project configurations”

Note:

Build| batch build 可以选择不同版本，而不是build all!!!

Build all 可以让你发布不同的版本！！！



2）也可以自己用makefile 自己nmake

//////////我个人各编译选项，高手指点/////////////////////////////////////////////////

nmake -f makefile.vc BUILD=release UNICODE=1 USE_OPENGL=1



ATTENTION：一定要修改build\msw\config.*对应的编译选项，否则无法编译

生成可执行文件在 ./vc_mx*/



///////////////////////////////////////////////////////////////////////////////////////////////////////////

You can pass arguments when invoking make or by editing build\msw\config.$(compiler) file

例如：

Visual C++:

  > nmake -f makefile.vc BUILD=debug UNICODE=1



Borland C++:

  > make -f makefile.bcc -DBUILD=debug -DUNICODE=1

  (Note that you have to use -D to set the variable, unlike in other make

  tools!)



注意一些默认选项：

请一定要读下面的选项说明！！！



（1）默认  multiLib mode （不要改好些吧）

              例如：#define wxUSE_ODBC 1 in setup.h 加入odbc支持



（2）USE_OPENGL=1  （default 不编译openGL）



（3）RUNTIME_LIBS=static

C运行时库？？

  Links static version of C and C++ runtime libraries into the executable, so

  that the program does not depend on DLLs provided with the compiler (e.g.

  Visual C++'s msvcrt.dll or Borland's cc3250mt.dll).

  Caution: Do not use static runtime libraries when building DLL (SHARED=1)!

（4）

BUILD=release

  Builds release version of the library. It differs from default 'debug'

  in lack of appended 'd' in name of library, does not define __WXDEBUG__

  and not include debug information compiled into object files and the

  executable.



SHARED=1

  Build shared libraries (DLLs). By default, DLLs are not built

  (SHARED=0).

Note：不知道有什么不同？

UNICODE=1

  To build Unicode versions of the libraries, add UNICODE=1 to make invocation

  (default is UNICODE=0). If you want to be able to use Unicode version on

  Windows9x, you will need to set MSLU=1 as well.



  This option affect name of the library ('u' is appended) and the directory

  where the library and setup.h are store (ditto).



WXUNIV=1

  Build wxUniversal instead of native wxMSW (see

http://www.wxwidgets.org/wxuniv.htm for more information).



Note: SGI 不依赖OS的GUI组件实现，不依赖MFC/Gtk

              不知道可用性如何？？









Note：如果想用 “模板“ 功能请注意编译选项



以下是针对各种编译器的编译方法（可以不看）

BC VC GCC/WinGW

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Using project files (VC++ 6 and later):



1. Unarchive wxWidgets-x.y.z-vc.zip, the VC++ 6 project

   makefiles (already included in wxMSW-x.y.z.zip and the setup version).

2. Open build\msw\wx.dsw, which has configurations for static

   compilation or DLL compilation, and each of these available in

   Unicode/ANSI, Debug/Release and wxUniversal or native variations.

   Normally you'll use a static linking ANSI configuration.

   Choose the Win32 Debug or Win32 Release configuration (or any other that

   suits your needs) and use Batch Build to compile _all_ projects. If you

   know you won't need some of the libraries (i.e. html part), you don't have

   to compile it.  It will also produce similar variations on jpeg.lib,

   png.lib, tiff.lib, zlib.lib, and regex.lib.

   If you want to build DLLs, you have to either build them one by one in

   proper order (jpeg, png, tiff, zlib, regex, expat, base, core, the rest

   in any order) or to use wx_dll.dsw workspace which has correct dependencies.

3. Open a sample project file, choose a configuration such as

   Win32 Debug using Build | Set Active Configuration..., and compile.

   The project files don't use precompiled headers, to save disk

   space, but you can switch PCH compiling on for greater speed.

   NOTE: you may also use samples/samples.dsw to access all

   sample projects without opening each workspace individually.

   You can use the Batch Build facility to make several samples

   at a time.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Using makefiles:



1. Change directory to build\msw. Type:



  'nmake -f makefile.vc'



   to make the wxWidgets core library as release DLL.

   See "Configuring the build" for instruction how to build debug or static

   libraries.



2. Change directory to samples and type 'nmake -f makefile.vc'

   to make all the samples. You can also make them individually.



Makefile notes:



  Use the 'clean' target to clean all objects, libraries and

  executables.



Note (1): if you wish to use templates, please edit

include\wx\msw\setup.h and set wxUSE_DEBUG_NEW_ALWAYS to 0.

Without this, the redefinition of 'new' will cause problems in

the headers. Alternatively, #undef new before including template headers.

You will also need to set wxUSE_IOSTREAMH to 0 if you will be

using templates, to avoid the non-template stream files being included

within wxWidgets.



Note (2): libraries and applications generated with makefiles and

project files are now (hopefully) compatible where static libraries

are concerned, but please exercise caution nevertheless and if

possible, use one method or the other.



Note (3): some crash problems can be due to inconsistent compiler

options. If strange/weird/impossible things start to happen please

check (dumping IDE project file as makefile and doing text comparison

if necessary) that the project settings, especially the list of defined

symbols, struct packing, etc. are exactly the same for all items in

the project. After this, delete everything (including PCH) and recompile.



Note (4): to create your own IDE files, copy .dsp and .dsw

files from an existing wxWidgets sample and adapt them, or

visit http://wiki.wxwindows.org/wiki.pl?MSVC.



Borland C++ 5.0/5.5 compilation

----------------------------------------------------------------



Compiling using the makefiles (updated 24 Sept 02):



1. Change directory to build\msw. Type 'make -f makefile.bcc' to

   make the wxWidgets core library. Ignore the compiler warnings.

   This produces a couple of libraries in the lib\bcc_lib directory.



2. Change directory to a sample or demo such as samples\minimal, and type

  'make -f makefile.bcc'. This produces a windows exe file - by default

   in the bcc_mswd subdirectory.



Note (1): the wxWidgets makefiles assume dword structure alignment. Please

make sure that your own project or makefile settings use the

same alignment, or you could experience mysterious crashes. To

change the alignment, change CPPFLAGS in build\msw\config.bcc.



Note (2): if you get undefined _SQL... symbols at link time,

either install odbc32.lib from the BC++ CD-ROM into your BC++ lib

directory, or set wxUSE_ODBC to 0 in include\wx\msw\setup.h and

recompile wxWidgets. The same applies if compiling using the IDE.



Note (3): If you wish debug messages to be sent to the console in

debug mode, edit makefile.bcc and change /aa to /Tpe in link commands.



Compiling using the IDE files for Borland C++ 5.0: not supported - please

use version 2.4.1 (using the make utility in commandline mode works fine_



Compiling using CBuilder (v1-v6): not supported - please

use version 2.4.1 (using the make utility in commandline mode works fine_



** REMEMBER **



In all of your wxWidgets applications, your source code should include

the following preprocessor directive:



#ifdef __BORLANDC__

#pragma hdrstop

#endif



(check the samples -- e.g., \wx2\samples\minimal\minimal.cpp -- for

more details)



Borland 16 Bit compilation for Windows 3.1

----------------------------------------------------------------

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////





Configuring the build

================================================================



So far the instructions only explained how to build release DLLs of wxWidgets

and did not cover any configuration. It is possible to change many aspects of

the build, including debug/release and ANSI/Unicode settings. All makefiles in

build\msw directory use same options (with a few exceptions documented below)

and the only difference between them is in object files and library directory

names and in make invocation command.



Changing the settings

----------------------------------------------------------------



There are two ways to modify the settings: either by passing the values as

arguments when invoking make or by editing build\msw\config.$(compiler) file

where $(compiler) is same extension as the makefile you use has (see below).

The latter is good for setting options that never change in your development

process (e.g. GCC_VERSION or VENDOR). If you want to build several versions of

wxWidgets and use them side by side, the former method is better. Settings in

config.* files are shared by all makefiles (samples, contrib, main library),

but if you pass the options as arguments, you must use same arguments you used

for the library when building samples or contrib libraries!



Examples of invoking make in Unicode debug build (other options described

below are set analogically):



Visual C++:

  > nmake -f makefile.vc BUILD=debug UNICODE=1



Borland C++:

  > make -f makefile.bcc -DBUILD=debug -DUNICODE=1

  (Note that you have to use -D to set the variable, unlike in other make

  tools!)



Watcom C/C++:

  > wmake -f makefile.wat BUILD=debug UNICODE=1



MinGW using native makefiles:

  > mingw32-make -f makefile.gcc BUILD=debug UNICODE=1



MinGW using configure or Cygwin:

  > ./configure --enable-debug --enable-unicode

  (see ./configure --help on details; configure is not covered in this

  section)



Brief explanation of options and possible values is in every

build\msw\config.* file; more detailed description follows.



Basic options

----------------------------------------------------------------



BUILD=release

  Builds release version of the library. It differs from default 'debug'

  in lack of appended 'd' in name of library, does not define __WXDEBUG__

  and not include debug information compiled into object files and the

  executable.



SHARED=1

  Build shared libraries (DLLs). By default, DLLs are not built

  (SHARED=0).



UNICODE=1

  To build Unicode versions of the libraries, add UNICODE=1 to make invocation

  (default is UNICODE=0). If you want to be able to use Unicode version on

  Windows9x, you will need to set MSLU=1 as well.



  This option affect name of the library ('u' is appended) and the directory

  where the library and setup.h are store (ditto).



WXUNIV=1

  Build wxUniversal instead of native wxMSW (see

  http://www.wxwidgets.org/wxuniv.htm for more information).



Advanced options

----------------------------------------------------------------



MONOLITHIC=1

  Starting with version 2.5.1, wxWidgets has the ability to be built as

  several smaller libraries instead of single big one as used to be the case

  in 2.4 and older versions. This is called "multilib build" and is the

  default behaviour of makefiles. You can still build single library

  ("monolithic build") by setting MONOLITHIC variable to 1.



USE_GUI=0

  Disable building GUI parts of the library, build only wxBase components used

  by console applications. Note that if you leave USE_GUI=1 then both wxBase

  and GUI libraries are built. If you are building monolithic library, then

  you should set wxUSE_GUI to 1 in setup.h.



USE_OPENGL=1

  Build wxmsw25_gl.lib library with OpenGL integration class wxGLCanvas.

  You must also modify your setup.h to #define wxUSE_GLCANVAS 1. Note that

  OpenGL library is always built as additional library, even in monolithic

  build!



USE_ODBC=1

  Build two additional libraries in multilib mode, one with database

  classes and one with wxGrid database support. You must

  #define wxUSE_ODBC 1 in setup.h



USE_HTML=0

  Do not build wxHTML library. If MONOLITHIC=1, then you must also

  #define wxUSE_HTML 1 in setup.h.



USE_XRC=0

  Do not build XRC resources library. If MONOLITHIC=1, then you must also

  #define wxUSE_HTML 1 in setup.h.



RUNTIME_LIBS=static

  Links static version of C and C++ runtime libraries into the executable, so

  that the program does not depend on DLLs provided with the compiler (e.g.

  Visual C++'s msvcrt.dll or Borland's cc3250mt.dll).

  Caution: Do not use static runtime libraries when building DLL (SHARED=1)!



MSLU=1

  Enables MSLU (Microsoft Layer for Unicode). This setting makes sense only if

  used together with UNICODE=1. If you want to be able to use Unicode version

  on Windows9x, you will need MSLU (Microsoft Layer for Unicode) runtime DLL

  and import lib.  The former can be downloaded from Microsoft, the latter is

  part of the latest Platform SDK from Microsoft (see msdn.microsoft.com for

  details). An alternative implementation of import library can be downloaded

  from http://libunicows.sourceforge.net - unlike the official one, this one

  works with other compilers and does not require 300+ MB Platform SDK update.



DEBUG_FLAG=0

DEBUG_FLAG=1

  If set to 1, define __WXDEBUG__ symbol, append 'd' to library name and do

  sanity checks at runtime. If set to 0, don't do it. By default, this is

  governed by BUILD option (if 'debug', DEBUG_FLAG=1, if 'release' it is 0),

  but it is sometimes desirable to modify default behaviour and e.g. define

  __WXDEBUG__ even in release builds.



DEBUG_INFO=0

DEBUG_INFO=1

  Same as DEBUG_FLAG in behaviour, this option affects whether debugging

  information is included in the executable or not.



VENDOR=<your company name>

  Set this to a short string identifying your company if you are planning to

  distribute wxWidgets DLLs with your application. Default value is 'custom'.

  This string is included as part of DLL name. wxWidgets DLLs contain compiler

  name, version information and vendor name in them. For example

  wxmsw250_core_bcc_custom.dll is one of DLLs build using Borland C++ with

  default settings. If you set VENDOR=mycorp, the name will change to

  wxmsw250_core_bcc_mycorp.dll.



CFG=<configuration name>

  Sets configuration name so that you can have multiple wxWidgets builds with

  different setup.h settings coexisting in same tree. See "Object and library

  directories" below for more information.



Compiler specific options

----------------------------------------------------------------



* MinGW



If you are using gcc-2.95 instead of gcc3, you must set GCC_VERSION to

2.95. In build\msw\config.gcc, change

> GCC_VERSION = 3

to

> GCC_VERSION = 2.95



* Visual C++



DEBUG_RUNTIME_LIBS=0

DEBUG_RUNTIME_LIBS=1

  If set to 1, msvcrtd.dll is used, if to 0, msvcrt.dll is used. By default

  msvcrtd.dll is used only if the executable contains debug info and

  msvcrt.dll if it doesn't. It is sometimes desirable to build with debug info

  and still link against msvcrt.dll (e.g. when you want to ship the app to

  customers and still have usable .pdb files with debug information) and this

  setting makes it possible.



Fine-tuning the compiler

----------------------------------------------------------------



All makefiles have variables that you can use to specify additional options

passed to the compiler or linker. You won't need this in most cases, but if you

do, simply add desired flags to CFLAGS (for C compiler), CXXFLAGS (for C++

compiler), CPPFLAGS (for both C and C++ compiler) and LDFLAGS (the linker).



Object and library directories

----------------------------------------------------------------



All object files produced during library build are stored in a directory under

build\msw. It's name is derived from build settings and CFG variable and from

compiler name. Examples of directory names:



  build\msw\bcc_msw            SHARED=0

  build\msw\bcc_mswdll         SHARED=1

  build\msw\bcc_mswunivd       SHARED=0, WXUNIV=1, BUILD=debug

  build\msw\vc_mswunivd        ditto, with Visual C++



Libraries and DLLs are copied into subdirectory of lib directory with

name derived from compiler and static/DLL setting and setup.h into directory

with name that contains other settings:



  lib\bcc_msw

  lib\bcc_lib\msw\wx\setup.h

  lib\bcc_dll

  lib\bcc_dll\msw\wx\setup.h

  lib\bcc_lib

  lib\bcc_lib\mswunivd\wx\setup.h

  lib\vc_lib

  lib\vc_lib\mswunivd\wx\setup.h



Each lib\ subdirectory has wx subdirectory with setup.h as seen above.

This file is copied there from include\wx\msw\setup.h (and if it doesn't exist,

from include\wx\msw\setup0.h) and this is the copy of setup.h that is used by

all samples and should be used by your apps as well. If you are doing changes

to setup.h, you should do them in this file, _not_ in include\wx\msw\setup.h.



If you set CFG to something, the value is appended to directory names. E.g.

for CFG=MyBuild, you'll have object files in



  build\msw\bcc_mswMyBuild

  build\msw\bcc_mswdllMyBuild

  etc.



and libraries in



  lib\bcc_libMyBuild

  lib\bcc_dllMyBuild

  etc.



By now it is clear what CFG is for: builds with different CFG settings don't

share any files and they use different setup.h files. This allows you to e.g.

have two static debug builds, one with wxUSE_SOCKETS=0 and one with sockets

enabled (without CFG, both of them would be put into same directory and there

would be conflicts between the files).



General Notes

=================================================================

- Debugging: under Windows 95, debugging output isn't output in

  the same way that it is under NT or Windows 3.1.

  Please see DebugView available from http://www.sysinternals.com.