| 1 | wxWindows naming conventions |
| 2 | ============================ |
| 3 | |
| 4 | Being a cross platform development library, it is naturally desirable |
| 5 | (at least to me ;) for wxWindows to be exploited in a fully cross |
| 6 | platform development environment -- a single invocation of make should |
| 7 | be sufficient to build target executables for a variety of host platforms |
| 8 | when desired. |
| 9 | |
| 10 | Since this is now in fact possible for at least the most commonly used |
| 11 | platforms, wxWindows has been structured to allow multiple, simultaneous |
| 12 | installations of the library. Common files are shared, platform and port |
| 13 | specific files and libraries are arranged so as to be unambiguous when |
| 14 | installed together. |
| 15 | |
| 16 | To manage this sanely we need a sufficiently descriptive and logical |
| 17 | labelling convention for file and install path names -- this document (at |
| 18 | least at its time of writing) describes the system we have adopted. |
| 19 | |
| 20 | It is not fine grained enough to include every possible build configuration |
| 21 | for wxWindows, but is encompassing enough to maintain a relatively complete |
| 22 | set of cross platform build tools on a single machine and to provide an |
| 23 | obvious slot for new ports to slip into. |
| 24 | |
| 25 | |
| 26 | For UNIX libraries, the canonical library name shall be of the form: |
| 27 | |
| 28 | libwx_$(toolkit)$(widgetset)$(debug)-$(version)-$(host).$(lib_extension) |
| 29 | |
| 30 | For MSW (native hosted only) libraries the library name should be of |
| 31 | the form: |
| 32 | |
| 33 | wx$(toolkit)$(widgetset)$(version)$(unicode)$(debug).$(lib_extension) |
| 34 | |
| 35 | |
| 36 | Where: |
| 37 | |
| 38 | -------------------------------------------------------------------- |
| 39 | |
| 40 | $toolkit must currently be one of the following: |
| 41 | |
| 42 | msw |
| 43 | gtk |
| 44 | base |
| 45 | mac |
| 46 | os2 |
| 47 | pm |
| 48 | mgl |
| 49 | motif |
| 50 | |
| 51 | -------------------------------------------------------------------- |
| 52 | |
| 53 | $widgetset may be one of: |
| 54 | |
| 55 | univ |
| 56 | |
| 57 | or empty if the widget set is the same as the toolkit. |
| 58 | |
| 59 | -------------------------------------------------------------------- |
| 60 | |
| 61 | $version is a string encoding the full version (major, minor, release) |
| 62 | for MSW, or just the major and minor number for UNIX. |
| 63 | |
| 64 | eg. for wxWindows 2.3.2, $version = 232 for MSW or 2.3 for UNIX. |
| 65 | |
| 66 | The rationale for this is that under UNIX-like systems it is desirable |
| 67 | that differently 'minor numbered' releases can be installed together, |
| 68 | meaning your old 2.2 apps can continue to work even if you migrate |
| 69 | development to the next stable or unstable release (eg. 2.3, 2.4), |
| 70 | but binary compatibility is maintained between point releases (those |
| 71 | with the same major.minor number) |
| 72 | |
| 73 | A known break in binary compatibility should be addressed by updating |
| 74 | the library soname (see the notes in configure.in for details on this) |
| 75 | |
| 76 | I do not know why MSW should not also omit the release number from |
| 77 | $version. (maybe that will change by the time this document is ratified) |
| 78 | |
| 79 | -------------------------------------------------------------------- |
| 80 | |
| 81 | $unicode and $debug are either empty or set to 'u' and 'd' |
| 82 | respectively when enabled. |
| 83 | |
| 84 | -------------------------------------------------------------------- |
| 85 | |
| 86 | $host is empty for a 'native' library, (that is one where the host |
| 87 | system is the same as the build system) or set to the value returned |
| 88 | by the autoconf ${host_alias} variable in configure for libraries |
| 89 | that are cross compiled. |
| 90 | |
| 91 | -------------------------------------------------------------------- |
| 92 | |
| 93 | $lib_extension is system specific and most usually set to .a for |
| 94 | a static library, .dll for a MSW shared library, or .so.$so_version |
| 95 | for a shared UNIX library. |
| 96 | |
| 97 | ==================================================================== |
| 98 | |
| 99 | |
| 100 | The installed location of the library specific setup.h is also |
| 101 | determined by the values of these items. On UNIX systems they |
| 102 | will be found in: |
| 103 | |
| 104 | $(prefix)/lib/wx/include/$(toolkit)$(widgetset)$(debug)-$(version)-$(host)/wx/ |
| 105 | |
| 106 | which will be in the include search path returned by the relevant |
| 107 | wx-config for that library. (or presumably set in the relevant |
| 108 | make/project files for platforms that do not use wx-config) |
| 109 | |
| 110 | ==================================================================== |
| 111 | |
| 112 | |
| 113 | The port specific wx-config file for each library shall be named: |
| 114 | |
| 115 | wx-$(toolkit)$(widgetset)$(debug)-$(version)-$(host)-config |
| 116 | |
| 117 | ${prefix}/bin/wx-config shall exist as a link to (or copy of) one of |
| 118 | these port specific files (on platforms which support it) and as such |
| 119 | it defines the default build configuration for wxApps on the system. |
| 120 | It may be modified by the system user at any time. |
| 121 | |
| 122 | |
| 123 | |
| 124 | ---==O==--- |
| 125 | |