|
1 /**************************************************************************** |
|
2 ** |
|
3 ** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies). |
|
4 ** All rights reserved. |
|
5 ** Contact: Nokia Corporation (qt-info@nokia.com) |
|
6 ** |
|
7 ** This file is part of the documentation of the Qt Toolkit. |
|
8 ** |
|
9 ** $QT_BEGIN_LICENSE:LGPL$ |
|
10 ** No Commercial Usage |
|
11 ** This file contains pre-release code and may not be distributed. |
|
12 ** You may use this file in accordance with the terms and conditions |
|
13 ** contained in the Technology Preview License Agreement accompanying |
|
14 ** this package. |
|
15 ** |
|
16 ** GNU Lesser General Public License Usage |
|
17 ** Alternatively, this file may be used under the terms of the GNU Lesser |
|
18 ** General Public License version 2.1 as published by the Free Software |
|
19 ** Foundation and appearing in the file LICENSE.LGPL included in the |
|
20 ** packaging of this file. Please review the following information to |
|
21 ** ensure the GNU Lesser General Public License version 2.1 requirements |
|
22 ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. |
|
23 ** |
|
24 ** In addition, as a special exception, Nokia gives you certain additional |
|
25 ** rights. These rights are described in the Nokia Qt LGPL Exception |
|
26 ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. |
|
27 ** |
|
28 ** If you have questions regarding the use of this file, please contact |
|
29 ** Nokia at qt-info@nokia.com. |
|
30 ** |
|
31 ** |
|
32 ** |
|
33 ** |
|
34 ** |
|
35 ** |
|
36 ** |
|
37 ** |
|
38 ** $QT_END_LICENSE$ |
|
39 ** |
|
40 ****************************************************************************/ |
|
41 |
|
42 /*! |
|
43 \page sharedlibrary.html |
|
44 \title Creating Shared Libraries |
|
45 |
|
46 \ingroup best-practices |
|
47 |
|
48 The following sections list certain things that should be taken into |
|
49 account when creating shared libraries. |
|
50 |
|
51 \section1 Using Symbols from Shared Libraries |
|
52 |
|
53 Symbols - functions, variables or classes - contained in shared libraries |
|
54 intended to be used by \e{clients}, such as applications or other |
|
55 libraries, must be marked in a special way. These symbols are called |
|
56 \e{public symbols} that are \e{exported} or made publicly visible. |
|
57 |
|
58 The remaining symbols should not be visible from the outside. On most |
|
59 platforms, compilers will hide them by default. On some platforms, a |
|
60 special compiler option is required to hide these symbols. |
|
61 |
|
62 When compiling a shared library, it must be marked for \e{export}. To use |
|
63 the shared library from a client, some platforms may require a special |
|
64 \e{import} declaration as well. |
|
65 |
|
66 Depending on your target platform, Qt provides special macros that contain |
|
67 the necessary definitions: |
|
68 \list |
|
69 \o \c{Q_DECL_EXPORT} must be added to the declarations of symbols used |
|
70 when compiling a shared library. |
|
71 \o \c{Q_DECL_IMPORT} must be added to the declarations of symbols used |
|
72 when compiling a client that uses the shared library. |
|
73 \endlist |
|
74 |
|
75 Now, we need to ensure that the right macro is invoked -- whether we |
|
76 compile a share library itself, or just the client using the shared |
|
77 library. |
|
78 Typically, this can be solved by adding a special header. |
|
79 |
|
80 Let us assume we want to create a shared library called \e{mysharedlib}. |
|
81 A special header for this library, \c{mysharedlib_global.h}, looks like |
|
82 this: |
|
83 |
|
84 \code |
|
85 #include <QtCore/QtGlobal> |
|
86 |
|
87 #if defined(MYSHAREDLIB_LIBRARY) |
|
88 # define MYSHAREDLIB_EXPORT Q_DECL_EXPORT |
|
89 #else |
|
90 # define MYSHAREDLIB_EXPORT Q_DECL_IMPORT |
|
91 #endif |
|
92 \endcode |
|
93 |
|
94 In the \c{.pro} file of the shared library, we add: |
|
95 |
|
96 \code |
|
97 DEFINES += MYSHAREDLIB_LIBRARY |
|
98 \endcode |
|
99 |
|
100 In each header of the library, we specify the following: |
|
101 |
|
102 \code |
|
103 #include "mysharedlib_global.h" |
|
104 |
|
105 MYSHAREDLIB_EXPORT void foo(); |
|
106 class MYSHAREDLIB_EXPORT MyClass... |
|
107 \endcode |
|
108 This ensures that the right macro is seen by both library and clients. We |
|
109 also use this technique in Qt's sources. |
|
110 |
|
111 |
|
112 \section1 Header File Considerations |
|
113 |
|
114 Typically, clients will include only the public header files of shared |
|
115 libraries. These libraries might be installed in a different location, when |
|
116 deployed. Therefore, it is important to exclude other internal header files |
|
117 that were used when building the shared library. |
|
118 |
|
119 For example, the library might provide a class that wraps a hardware device |
|
120 and contains a handle to that device, provided by some 3rd-party library: |
|
121 |
|
122 \code |
|
123 #include <footronics/device.h> |
|
124 |
|
125 class MyDevice { |
|
126 private: |
|
127 FOOTRONICS_DEVICE_HANDLE handle; |
|
128 }; |
|
129 \endcode |
|
130 |
|
131 A similar situation arises with forms created by Qt Designer when using |
|
132 aggregation or multiple inheritance: |
|
133 |
|
134 \code |
|
135 #include "ui_widget.h" |
|
136 |
|
137 class MyWidget : public QWidget { |
|
138 private: |
|
139 Ui::MyWidget m_ui; |
|
140 }; |
|
141 \endcode |
|
142 |
|
143 When deploying the library, there should be no dependency to the internal |
|
144 headers \c{footronics/device.h} or \c{ui_widget.h}. |
|
145 |
|
146 This can be avoided by making use of the \e{Pointer to implementation} |
|
147 idiom described in various C++ programming books. For classes with |
|
148 \e{value semantics}, consider using QSharedDataPointer. |
|
149 |
|
150 |
|
151 \section1 Binary compatibility |
|
152 |
|
153 For clients loading a shared library, to work correctly, the memory |
|
154 layout of the classes being used must match exactly the memory layout of |
|
155 the library version that was used to compile the client. In other words, |
|
156 the library found by the client at runtime must be \e{binary compatible} |
|
157 with the version used at compile time. |
|
158 |
|
159 This is usually not a problem if the client is a self-contained software |
|
160 package that ships all the libraries it needs. |
|
161 |
|
162 However, if the client application relies on a shared library that belongs |
|
163 to a different installation package or to the operating system, then we |
|
164 need to think of a versioning scheme for shared libraries and decide at |
|
165 which level \e{Binary compatibility} is to be maintained. For example, Qt |
|
166 libraries of the same \e{major version number} are guaranteed to be binary |
|
167 compatible. |
|
168 |
|
169 Maintaining \e{Binary compatibility} places some restrictions on the changes |
|
170 you can make to the classes. A good explanation can be found at |
|
171 \l{http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++} |
|
172 {KDE - Policies/Binary Compatibility Issues With C++}. These issues should |
|
173 be considered right from the start of library design. |
|
174 We recommend that the principle of \e{Information hiding} and the |
|
175 \e{Pointer to implementation} technique be used wherever possible. |
|
176 */ |