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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
