QT如何创建适用于不同的库

http://doc.qt.nokia.com/latest/sharedlibrary.html

?

"ui_widget.h" class MyWidget : public QWidget { private: Ui::MyWidget m_ui; };

When deploying the library, there should be no dependency to the internal headers?footronics/device.h?or?ui_widget.h.

This can be avoided by making use of the?Pointer to implementation?idiom described in various C++ programming books. For classes with?value semantics, consider using?QSharedDataPointer.

Binary compatibility

For clients loading a shared library, to work correctly, the memory layout of the classes being used must match exactly the memory layout of the library version that was used to compile the client. In other words, the library found by the client at runtime must be?binary compatible?with the version used at compile time.

This is usually not a problem if the client is a self-contained software package that ships all the libraries it needs.

However, if the client application relies on a shared library that belongs to a different installation package or to the operating system, then we need to think of a versioning scheme for shared libraries and decide at which level?Binary compatibility?is to be maintained. For example, Qt libraries of the same?major version number?are guaranteed to be binary compatible.

Maintaining?Binary compatibility?places some restrictions on the changes you can make to the classes. A good explanation can be found at?KDE - Policies/Binary Compatibility Issues With C++. These issues should be considered right from the start of library design. We recommend that the principle of?Information hiding?and thePointer to implementation?technique be used wherever possible.