Forwarding from a mail exchange with Alexander and Clinton. -- Stephen Kelly <stephen.ke...@kdab.com> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions
--- Begin Message ---On Sunday, January 08, 2012 11:21:04 am Stephen Kelly wrote: > Hi guys, > > feature freeze for Qt 5 is coming up, so we need to ensure that the CMake > stuff does all we need it to do for the 5.0 release, and that we can keep > source compatibility for it. > > The config files basically work for simple cases of using a shared Qt. They > also work for simple cases of using a static Qt (where the caller specifies > the static dependencies, and plugins are not used). Because the plugins are > not listed, it's probably not very useful for cpack stuff yet (or Mike > McArthurs DeployQt4 stuff). > > Is there anything else missing? Do you think we should push to try and get > more in before feature freeze? > > Clinton, you were talking about the QT_DEBUG and QT_NO_DEBUG stuff before, > and I thought you would need to post to the mailing list about it, but you > never did. Should we add one or other of them to the Qt5Core_DEFINITIONS > based on whether the Qt is a release build or not? Could you at least > repeat the issue here so we can find out if it's something that needs to > be resolved?Which mailing list is it? I'm not on a Qt dev list, and it seems they've been changing around. The problem is qglobal.h has #if !defined(QT_NO_DEBUG) && !defined(QT_DEBUG) # define QT_DEBUG #endif so quite often a CMake user using FindQt4.cmake, but not using UseQt4.cmake would get into a case where the headers think its a debug build but the release Qt libraries are linked in. The usual symptom is that custom Qt plugins do not work on Windows because qplugin.h's Q_EXPORT_PLUGIN2() macro uses QT_NO_DEBUG. There are also other Qt macros that use QT_NO_DEBUG such as Q_ASSERT(). The MSVC/MinGW users see this problem, because on Windows, there are separate debug/release libraries. Why they are separate for MinGW, is beyond me because MinGW doesn't have separate debug/release runtimes. Putting the variable in Qt5Core_DEFINITIONS only works when using CMAKE_BUILD_TYPE, but will not work if using CMAKE_CONFIGURATION_TYPES. I would assume most Windows users use something like visual studio where CMAKE_CONFIGURATION_TYPES is used. To fix this, I was thinking of basing QT_DEBUG/QT_NO_DEBUG off of NDEBUG by default, instead of always assuming QT_DEBUG if neither are defined. diff --git a/src/corelib/global/qglobal.h b/src/corelib/global/qglobal.h index 20f3ca9..840cb76 100644 --- a/src/corelib/global/qglobal.h +++ b/src/corelib/global/qglobal.h @@ -1643,6 +1643,12 @@ inline void qUnused(T &x) { (void)x; } # define QT_NO_DEBUG #endif +/* Use NDEBUG as a hint for setting the default QT_NO_DEBUG/QT_DEBUG, but + allow the user to override it. */ +#if defined(NDEBUG) && !defined(QT_NO_DEBUG) && !defined(QT_DEBUG) +# define QT_NO_DEBUG +#endif + #if !defined(QT_NO_DEBUG) && !defined(QT_DEBUG) # define QT_DEBUG #endif That should avoid the entire issue with MSVC users, because one must always choose a build type. MinGW/Makefiles can compile without a build type so those users could still see the problem of plugins not loading, and Linux users could still see undesirable behavior for things like Q_ASSERT() if a build type is not set. Both of those can be handled by looking at CMAKE_BUILD_TYPE and adding the correct definition to Qt5Core_DEFINITIONS. Clint > > I ported GammaRay to Qt5 and the new CMake system last week. See my commits > from Jan 5 here: > > https://github.com/KDAB/GammaRay/commits/master > > Particularly > > https://github.com/KDAB/GammaRay/commit/affbba909b8b54d82e39a82e60db7483498 > 2315c > > contains the port by introducing a porting file (which allows building the > same code with Qt 4 and 5) containing wrappers for macros etc, backward > compatibility variables and the qt4_automoc macro, which is not in Qt5. > > It's not complete (I only put as much stuff in there as GammaRay needs), > but I think something like that will be part of all projects that port > from Qt 4 to 5 and which use CMake. The CMake stuff is the most source > incompatible changes in such a port (because of modularity, no USE files, > qt4_automoc removed etc). I wonder if we should install such a file from > somewhere (from Qt itself or from ecm etc). > > I'd appreciate if you have a think about this stuff and read the config > files again that I posted to the cmake mailing list before. Let me know if > there are remaining issues for 5.0 and what we should aim for for 5.1. > > Thanks, -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com
--- End Message ---
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
