Cross-Platform GUI Programming with wxWidgets

Configuration/Build Options

wxWidgets can be built using almost countless permutations of configuration options. However, four main options are available on all platforms:

  • Release versus Debug: Debug builds include debug information and extra checking code, whereas release builds omit debug information and enable some level of optimization. It is strongly recommended that you develop your application using a debug version of the library to benefit from the debug assertions that can help locate bugs and other problems.

  • Unicode versus non-Unicode: As discussed in Chapter 16, "Writing International Applications," Unicode facilitates the display of non-ASCII characters such as Cyrillic, Greek, Korean, Japanese, and so on. wxWidgets natively supports Unicode; there is no penalty for using Unicode in terms of available features (with the exception of wxODBC on Unix), nor is any additional coding required. Windows 95, 98, and ME do not have built-in Unicode support, but wxWidgets can be configured to use the add-on MSLU library for these operating systems.

  • Static versus Shared: A static version of the library is linked with the application at compile time, whereas a shared version is linked at runtime. Using a static library results in a larger application but also relieves the end user of the need for installing shared libraries on his or her computer. On Linux and Mac OS X, static libraries end in .a, and on Windows, they end in .lib. On Linux and Mac OS X, shared libraries end in .so, and on Windows, they end in .dll. Note that there are certain memory and performance implications of static and shared libraries that are not specific to wxWidgets; they are beyond the scope of this book.

  • Multi-lib versus Monolithic: The entire wxWidgets library is made up of modules that separate the GUI functionality from the non-GUI functionality as well as separate advanced features that are not frequently needed. This separation enables you to use wxWidgets modules selectively depending on your specific needs. Alternatively, you can build wxWidgets into one "monolithic" library that contains all of the wxWidgets modules in one library file.

You can build and simultaneously use more than one version and/or configuration of wxWidgets. The way you access the different builds depends on your platform, but all library files are created using a standard naming convention: wx<library><version><u><d> where u and d indicate Unicode and debug, respectively. For example, the file wxbase26ud.lib is the Unicode debug base library for wxWidgets 2.6, and wxmsw26u_core contains the core GUI elements for a Unicode release build on Windows.

After building wxWidgets, you can confirm that the library is built correctly by compiling and running one of the samples. The samples are located in the samples folder of the main wxWidgets directory, with each sample in its own subfolder. You might try samples/minimal first because it's the simplest. For each compiler, directions for building one of the samples are included in docs/<platform>/install.txt. There are also more complete applications in the demos directory, and though they are not discussed here, they are built almost identically to the samples in most cases.

It is important to note that you can build wxWidgets with makefiles on any platform but still use an IDE to develop your projects. For example, you can use the Microsoft Visual C++ command-line compiler to build wxWidgets but still use Microsoft Visual Studio to create your applications.

    Категории