]>
Commit | Line | Data |
---|---|---|
feebe03b DS |
1 | wxWindows naming conventions |
2 | ============================ | |
0cefee80 RL |
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 | |
2edb0bde | 18 | least at its time of writing) describes the system we have adopted. |
0cefee80 RL |
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 |