Chapter 2: Basic wxWidgets Information
PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks (v4.6) Page 5 of 50
2 Basic wxWidgets Information
2.1 wxWidgets Versions
wxWidgets has two supported branches, called stable (currently 3.2) and development (currently 3.3). The stable branch
version always has an even minor version number (e.g., 3.0.5 or 3.2.2) while the development branch has an odd
number for its minor version (e.g., 3.1.7 or 3.3.0). The current development branch is also sometimes called “master”
(e.g., in the GIT code repository) or “trunk” (e.g., in the documentation version selector).
For wxWidgets, when the branch is called stable, the API and ABI of the Major.Minor version is sealed. This means
that all the versions in the stable branch are API- and binary-wise fully compatible, i.e., one can switch to newer releases
of the branch (e.g., from 3.2.0 to 3.2.2) without encountering any (adverse) compile- and run-time differences compared
to the older releases. No such guarantees are made for the development branch and in fact, as new features are added,
the API, ABI, or the run-time behaviour change. In other words, it does not mean that the stable branch is more stable
as in being less prone to crashing your application than the development one. However, it means that no new features
can be added to the stable branch after its initial release. The new releases in the stable branches are for bug fixes only,
but even not all bug fixes can be backported from the development to the stable branch, for example when the code for
the two branches has diverged too much or just no one felt motivated enough to do that. The core developers suggest
that the development branch is generally suitable for production use.
After several years of adding features to the development branch, the developers decide it is ready to become the
new stable branch (e.g., 3.1 became 3.2 after 3.1.7) and a new development branch is created (e.g., 3.3 split from 3.2.0
after its release).
The number of differences in features added (and possibly bugs fixed) between the two branches increases with
the time passed since the initial stable version release. At the time of writing, there has been no release in the current
development branch yet (for comparison, there were eight releases in 3.1 development branch, i.e., between the release
of 3.0 and 3.2). Therefore, if you want to use the development version, you need to embrace the “Live at Head” concept
and use the current GIT master. If you want to do this, make sure to read and follow the GIT instructions. Currently, the
biggest reason for using the development version may be the experimental support for Windows dark mode, about
which you can read about here.
2.2 Shared vs Static Linking
wxWidgets can be built either as the static build or the shared build (the application requires wxWidgets DLL at runtime)
library. Both have their pros and cons, so which one to choose depends on the use case. When the shared configuration
is used, all the necessary DLLs must be shipped with the application and the install package is usually larger than when
using the static libraries where only the used code is linked into the final executable. On the other hand, if one has a
suite of applications using wxWidgets, having them all using the same wxWidgets DLLs is desirable. Similarly, for
applications with plugins, linking to wxWidgets dynamically ensures that both the application and the plugin are using
the same library.
In practice, for most cases the differences from both the user and the programmer’s point of view are usually
negligible, with static linking perhaps being a bit more convenient regarding the application distribution but also being
slower when linking the application during its each and every build.
GCC allows linking the run-time libraries statically, so if all the libraries the application uses can be linked statically
and support being built with the statically-linked compiler run-time libraries, the whole application can be contained in a
single executable which does not require any DLLs at all (see chapters 3.6.7, 4.5.9, and 4.8.4).
I would use the static build only if the application was small, used just wxWidgets as the compiled library and I was
concerned about how much bandwidth and disk space the installer and the installed application take. Otherwise, I would
prefer dynamic linking, i.e., the shared build and this build will be preferably used in this guide.
