Re: [Development] wec2013 build fails with qt 5.6 beta in dbus.
On Monday 21 December 2015 21:58:46 Gunnar Roth wrote: > It's an unfortunate side effect of the configure.exe changes that enable > QtDBus > on all platforms. The code does work on Windows CE, but you have to figure out > why windows.h got included when it shouldn't have or tell it to stop > #define'ing interface. There's a include in mkspecs/common/wince/qplatformdefs.h. All of this sounds a lot like we need something like 32f957ccc68084fe11fcf23823c5094a1833a790 for this mkspec. Gunnar, does https://codereview.qt-project.org/#/c/144600/ fix the problem for you? BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_OBJECT and override
1) Add override (or rather Q_DECL_OVERRIDE) to the definition of
Q_OBJECT *and* all QObject-derived classes in Qt.
[...]
2) Remove override from all QObject-derived classes in Qt.
[...]
3) Explicitly disable the warning in the clang mkspecs.
[...]
4) Let users deal with the problem by making them turn the warning off.
[...]
1) is the thing to do, but OTOH it's a lot of work with questionable gain.
2) and 4) are very wrong. IMO, we shouldn't do this.
3) could be a good compromise. There's a variant of this solution by turning
the warning off
at the beginning of every header and turning it on again at the end.
We once had the QT_{BEGIN|END}_HEADER macros which could expand to
#pragma clang diagnostic push
#pragma clang diagnostic ignored -Wannoyingwarning
and repectively
#pragma clang diagnostic pop
This way the warning can be turned on for user code.
BR,
Joerg
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Hi Sascha, My point is that we cannot know whether we'll have to encode the platform in a function name again in the future, in which case we'll have functions with and without the platform in their name. Your point is that this won't ever happen. We can just avoid this risk of an inconsistent future API by using different namespaces. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Hi Thiago, This *is* the problem of Linux distributions. FHS doesn't cover this problem properly and this is the point where it should be fixed. You're making life harder for every platform - not only Linux - by fixing their problem. You may argue that case, but they'll argue back that this solution has worked quite well for almost all packages for over a decade. OK I'm accepting reality and that what worked for so long is assumed to be the right way and won't be changed. I'm even going so far to admit that we might have to act. :) What still is questionable is the way of doing that. What we have is a naming clash between two installed versions. IMHO the least elegant way is to rename all relevant files in one of these versions. For these kind of conflicts there are namespaces. Every file system that's relevant to our case has a namespace feature: subdirectories. Apparently this feature is out for /usr/bin. Even /usr/bin/X11 is a symlink to /usr/bin on Debian wheezy that I'm using here. But hey, here's an interesting example: llvm. Binaries are in /usr/lib/llvm-3.0/bin and /usr/bin contains symlinks to its contents. These symlinks end with llvm's version number. Same pattern applies to the 2.7 llvm version that's installed here. Why can't we have something alike for Qt? If your fear is that different distros use different link names then please take these things into consideration: - Our target audience is software developers, they'll be able to enter qmake, press TAB twice and choose the right link. (Well if the version number is appended and not prepended, anyways.) - We can publish a recommendation for packaging Qt. - Some distros might want to use a different naming scheme. If all of this is totally impossible then please add a configure option that's off by default, like -qtlibinfix. Cheers, Jörg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
