- #endif
- @endcode
-
- By default the @c WXWIN_COMPATIBILITY@e _X_X macro is set
- to 1 for the previous stable branch, for example
- in @c 2.6.x @c WXWIN_COMPATIBILITY_2_4 = 1. For the next earlier
- stable branch the default is 0, so @c WXWIN_COMPATIBILITY_2_2 = 0
- for @c 2.6.x. Earlier than that, obsolete features are removed.
-
- These macros can be changed in @c setup.h. Or on UNIX-like systems you can
- set them using the @c --disable-compat24 and @c --enable-compat22
- options to @c configure.
-
- They can be useful in two ways:
-
- @li changing @c WXWIN_COMPATIBILITY_2_4 to 0 can be useful to
- find uses of deprecated features in your program.
- @li changing @c WXWIN_COMPATIBILITY_2_2 to 1 can be useful to
- compile a program developed using @c 2.2.x that no longer compiles
- with @c 2.6.x.
-
- A program requiring one of these macros to be 1 will become
- incompatible with some future version of wxWidgets, and you should consider
- updating it.
-
-
-
- @section overview_backwardcompat_libbincompat Library binary compatibility
-
- For some platforms, releases from a stable branch are not only source level
- compatible but can also be binary compatible.
-
- Binary compatibility makes it possible to get the maximum benefit from
- using shared libraries, also known as dynamic link libraries (DLLs) on
- Windows or dynamic shared libraries on OS X.
-
- For example, suppose several applications are installed on a system requiring
- wxWidgets @c 2.6.0, @c 2.6.1 and @c 2.6.2. Since @c 2.6.2 is
- backward compatible with the earlier versions, it should be enough to
- install just wxWidgets @c 2.6.2 shared libraries, and all the applications
- should be able to use them. If binary compatibility is not supported, then all
- the required versions @c 2.6.0, @c 2.6.1 and @c 2.6.2 must be
- installed side by side.
-
- Achieving this, without the user being required to have the source code
- and recompile everything, places many extra constraints on the changes
- that can be made within the stable branch. So it is not supported for all
- platforms, and not for all versions of wxWidgets. To date it has mainly
- been supported by wxGTK for UNIX-like platforms.
-
- Another practical consideration is that for binary compatibility to work,
- all the applications and libraries must have been compiled with compilers
- that are capable of producing compatible code;
- that is, they must use the
- same ABI (Application Binary Interface). Unfortunately most different C++
- compilers do not produce code compatible with each other, and often even
- different versions of the same compiler are not compatible.
-
-
-
- @section overview_backwardcompat_appbincompat Application binary compatibility
-
- The most important aspect of binary compatibility is that applications
- compiled with one version of wxWidgets, e.g. @c 2.6.1, continue to work
- with shared libraries of a later binary compatible version, for example @c 2.6.2.
- The converse can also be useful however. That is, it can be useful for a
- developer using a later version, e.g. @c 2.6.2 to be able to create binary
- application packages that will work with all binary compatible versions of
- the shared library starting with, for example @c 2.6.0.
-
- To do this the developer must, of course, avoid any features not available
- in the earlier versions. However this is not necessarily enough;
- in some cases an application compiled with a later version may depend on it even
- though the same code would compile fine against an earlier version.
-
- To help with this, a preprocessor symbol @c wxABI_VERSION can be defined
- during the compilation of the application (this would usually be done in the
- application's makefile or project settings). It should be set to the lowest
- version that is being targeted, as a number with two decimal digits for each
- component, for example @c wxABI_VERSION=20600 for @c 2.6.0.
-
- Setting @c wxABI_VERSION should prevent the application from implicitly
- depending on a later version of wxWidgets, and also disables any new features
- in the API, giving a compile time check that the source is compatible with
- the versions of wxWidgets being targeted.
-
- Uses of @c wxABI_VERSION are stripped out of the wxWidgets sources when
- each new development branch is created. Therefore it is only useful to help
- achieve compatibility with earlier versions with the same major
- and even minor version numbers. It won't, for example, help you write
- code compatible with @c 2.4.x using wxWidgets @c 2.6.x.
+#endif
+@endcode
+
+By default the @c WXWIN_COMPATIBILITY_X_X macro is set to 1 for the previous
+stable branch, for example in 2.8.x, @c WXWIN_COMPATIBILITY_2_6 = 1. For the
+next earlier stable branch the default is 0, so @c WXWIN_COMPATIBILITY_2_4 = 0
+for 2.8.x. Earlier than that, obsolete features are removed.
+
+These macros can be changed in @c setup.h. Or on UNIX-like systems you can set
+them using the @c --disable-compat26 and @c --enable-compat24 options to
+configure.
+
+They can be useful in two ways:
+
+@li Changing @c WXWIN_COMPATIBILITY_2_6 to 0 can be useful to find uses of
+ deprecated features in your program that should eventually be removed.
+@li Changing @c WXWIN_COMPATIBILITY_2_4 to 1 can be useful to compile a program
+ developed using 2.4.x that no longer compiles with 2.8.x.
+
+A program requiring one of these macros to be 1 will become incompatible with
+some future version of wxWidgets, and you should consider updating it.
+
+
+@section overview_backwardcompat_libbincompat Library Binary Compatibility
+
+For some platforms, releases from a stable branch are not only source level
+compatible but can also be binary compatible.
+
+Binary compatibility makes it possible to get the maximum benefit from using
+shared libraries, also known as dynamic link libraries (DLLs) on Windows or
+dynamic shared libraries on OS X.
+
+For example, suppose several applications are installed on a system requiring
+wxWidgets 2.6.0, 2.6.1 and 2.6.2. Since 2.6.2 is backward compatible with the
+earlier versions, it should be enough to install just wxWidgets 2.6.2 shared
+libraries, and all the applications should be able to use them. If binary
+compatibility is not supported, then all the required versions 2.6.0, 2.6.1 and
+2.6.2 must be installed side by side.
+
+Achieving this, without the user being required to have the source code and
+recompile everything, places many extra constraints on the changes that can be
+made within the stable branch. So it is not supported for all platforms, and
+not for all versions of wxWidgets. To date it has mainly been supported by
+wxGTK for UNIX-like platforms.
+
+Another practical consideration is that for binary compatibility to work, all
+the applications and libraries must have been compiled with compilers that are
+capable of producing compatible code; that is, they must use the same ABI
+(Application Binary Interface). Unfortunately most different C++ compilers do
+not produce code compatible with each other, and often even different versions
+of the same compiler are not compatible.
+
+
+@section overview_backwardcompat_appbincompat Application Binary Compatibility
+
+The most important aspect of binary compatibility is that applications compiled
+with one version of wxWidgets, e.g. 2.6.1, continue to work with shared
+libraries of a later binary compatible version, for example 2.6.2. The converse
+can also be useful however. That is, it can be useful for a developer using a
+later version, e.g. 2.6.2 to be able to create binary application packages that
+will work with all binary compatible versions of the shared library starting
+with, for example 2.6.0.
+
+To do this the developer must, of course, avoid any features not available in
+the earlier versions. However this is not necessarily enough; in some cases an
+application compiled with a later version may depend on it even though the same
+code would compile fine against an earlier version.
+
+To help with this, a preprocessor symbol @c wxABI_VERSION can be defined during
+the compilation of the application (this would usually be done in the
+application's makefile or project settings). It should be set to the lowest
+version that is being targeted, as a number with two decimal digits for each
+component, for example @c wxABI_VERSION=20600 for 2.6.0.
+
+Setting @c wxABI_VERSION should prevent the application from implicitly
+depending on a later version of wxWidgets, and also disables any new features
+in the API, giving a compile time check that the source is compatible with the
+versions of wxWidgets being targeted.
+
+Uses of @c wxABI_VERSION are stripped out of the wxWidgets sources when each
+new development branch is created. Therefore it is only useful to help achieve
+compatibility with earlier versions with the same major and even minor version
+numbers. It won't, for example, help you write code compatible with 2.6.x using
+wxWidgets 2.8.x.
projects / wxWidgets.git / blobdiff