On 07 May 2014, at 11:15, Robert Knight <robertkni...@gmail.com> wrote: >> It is a very good idea to have the Qt files treated as system files. >> I’ve gone to great lengths to filter out the warnings from Qt in our CMake >> files > > I would caution against that. Could we just fix the warnings in Qt > headers instead?
I agree that would be ideal solution if Qt headers could be fixed to the point they don’t trigger any warnings with -Weverything flag on. This is obviously not possible, as many warnings are just warnings and Qt is complicated enough to use many non-obvious constructs. Therefore Qt have to settle on some level of warnings, probably closer to -Wall with some warnings disabled, and user is also forced to settle on the same level or lower. I compile my project on -Weverything with some warnings disabled (bad case of OCD I guess) and that wouldn’t be a satisfying solution for me. > I enabled suppression of warnings in Qt headers for a project a while > back and ended up suppressing > a real and serious warning that occurred when a generic class in Qt > was instantiated with a particular > type in my code. IIRC I was using QSharedPointer<T> with a 'T' which > was only forward-declared at the point where > ~QSharedPointer<T> ended up being instantiated. The normal warning got > suppressed because it occurred in the > Qt template class header even though the error was actually in > relation to my code. Perhaps user could have a choice whether he prefers Qt headers to be treated as system headers, but with current CMake’s exported target functionality I don’t see a good way to do that. > > Regards, > Rob. > > > On 7 May 2014 10:09, Mikołaj Siedlarek <msiedla...@nctz.net> wrote: >> On 07 May 2014, at 10:59, Kurt Pattyn <pattyn.k...@gmail.com> wrote: >>> On 06 May 2014, at 11:40, Mikołaj Siedlarek <msiedla...@nctz.net> wrote: >>> >>>> Hi, >>>> >>>> I’m on a quest to enable hack-free all-warnings-enabled building of my >>>> project using, among others, >>>> Qt and CMake. This requires that compiler treat Qt headers included in my >>>> code as “system headers” >>>> and not warn me about constructs used in them. >>>> >>>> I already contributed -iframework (Apple frameworks counterpart to >>>> -isystem) flag support to CMake >>>> (https://github.com/Kitware/CMake/pull/100), so with 3.0 version it should >>>> correctly handle properly >>>> marked include directories on all systems. >>>> >>>> The only problem is current CMake integration in Qt uses >>>> INTERFACE_INCLUDE_DIRECTORIES >>>> target property, when to be provide a system include directory it should >>>> use >>>> INTERFACE_SYSTEM_INCLUDE_DIRECTORIES. On compilers that do not support >>>> -isystem flag >>>> CMake falls back to -I, so compatibility would not be a problem. >>>> >>>> The problem is current CMake integration in Qt requires version 2.8.3, but >>>> INTERFACE_SYSTEM_INCLUDE_DIRECTORIES is only available since 2.8.12. >>>> Before I propose >>>> a patch I’d like to consult a maintainer of this system, or at least >>>> someone more familiar with >>>> Qt release process, whether it’s best to add some CMake version checks or >>>> version requirement >>>> can be bumped with next release. >>>> >>>> Please direct me to someone I can discuss this with, or tell me directly >>>> that my idea is bad. >>> It is a very good idea to have the Qt files treated as system files. I’ve >>> gone to great lengths to >>> filter out the warnings from Qt in our CMake files. It would be nice if >>> this was included out-of-the-box. >>> One problem that is not fixed by the system flag, is the auto-generated >>> files (moc files). >> >> I thought about that and I believe it could be fixed in CMake’s AUTOMOC >> functionality. I’ll look into it. >> >>> For those I have submitted a patch that should appear in Qt 5.3.1. >>> Personally I would not force version 2.8.12 as AFAIK that version is not >>> available out-of-the-box on Debian >>> for instance. >> >> Yes, it seems stable Debian has just been released with CMake 2.8.9, so it’s >> gonna be here for a while. >> A version check then and fallback to INTERFACE_INCLUDE_DIRECTORIES. >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
