[Development] Fixing the DLL/shared/static mess

[Thiago Macieira]

I ran into Ossi and Marius S.O. talking about the mess we have with the build 
and use of Qt as shared/DLL or static. It's something I had begun fixing, but I 
haven't finished yet.

If you're dealing with a different buildsystem than qmake, or you're packaging 
Qt, please my email that is a reply to this:

Problem 1:
 we have qmake CONFIG += static shared dll staticlib
 but each one has different behaviour due to the way that aliases work
 
Therefore:
 qmake CONFIG += staticlib and dll are *deprecated* as of now

Please use only shared and static only. Those configs determine whether your 
library output will be a static library or a shared library or DLL. They affect 
only compiler and linker build options, but not any DEFINES you may need when 
building your Windows DLL. That's entirely up to you.


Problem 2:
 we have QT_MAKEDLL, QT_DLL, QT_STATIC, QT_SHARED
 we only need one: QT_STATIC (exclusive of QT_SHARED)

Therefore, QT_MAKEDLL will be removed altogether.

Qt builds with -shared (the default) will have in qconfig.h:

#ifndef QT_STATIC
#define QT_SHARED
#define QT_DLL
#endif

Qt builds with -static will have in in qconfig.h:

#ifndef QT_SHARED
#define QT_STATIC
#endif

All the Q_*_EXPORT macros will be adapted to the form:

#ifndef QT_STATIC
#  ifdef QT_BUILD_XXX_LIB
#    define Q_XXX_EXPORT Q_DECL_EXPORT
#  else
#    define Q_XXX_EXPORT Q_DECL_IMPORT
#  endif
#else // QT_STATIC
#  define Q_XXX_EXPORT
#endif

Implications:

1) QT_STATIC determines the type of Qt that some code is *using*. Since all 
modules except for QtCore use another Qt module, this decision is valid for Qt 
as well. Therefore, *ALL* Qt libraries must be either static or shared. Mixed 
builds will not be supported

  This does not apply to QtPlatformSupport and winmain. Those are not 
considered Qt libraries: winmain is added implicitly to your Windows builds, 
whereas QtPlatformSupport is entirely private API. They will continue being 
distributed as .a and .lib files (for now, at least).

2) QT_STATIC should not be used for making decisions outside of Qt (i.e., 
modules built using qt_module_config.prf). You're entirely on your own if you 
do that.

3) If you're not doing that, we expect no impact to regular applications or 
libraries using Qt, no change necessary to your code or .pro files or whatever 
buildsystem (one exception, see next email)

4) Packagers who package only one type of Qt build (shared or static, but not 
both), should not see any changes either. One Qt build means a set of library 
files and the headers (e.g.: libQtCore.so and qconfig.h).


Over the next couple of weeks, we'll go over the Qt modules in qt5.git and 
adapt them to the macros. we'll also take the opportunity to move the 
Q_XXX_EXPORT macros to the library in question. qglobal.h will only define the 
macros for a subset of qtbase which can never be split apart (QtCore, 
QtNetwork, QtGui).

I really expect this to cause no breakages, but we'll only know more once we 
start doing and see what problems they might introduce.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120413/ea83b79a/attachment.sig>