> I compile my project on -Weverything with some warnings disabled > (bad case of OCD I guess)
I try to build with as many warnings enabled as possible and -Werror on as well, so I'm very much a fan of asking the compiler to be strict. The issue I mentioned above though cost me a lot of debugging time - and I'm someone who is fairly experienced with the language, tooling and Qt. Unfortunately marking something as a system header is a sledgehammer - it suppresses warnings in both non-generic code where the compiled code is independent of the context in which it is used but also in macros and templates where the compiled code is a combination of your own code and the code in the headers. > . This is obviously not possible, > as many warnings are just warnings and Qt is complicated enough to use many > non-obvious constructs. Do you have or could you get any stats on what warnings are remaining and with what frequency? When I disabled Qt warnings the main issue was that we wanted implicit lossy conversions to be errors in our code but there are a number of cases where Qt did this. I believe these have since been fixed though and -Wconversion is now used? Regards, Rob. On 7 May 2014 10:37, Mikołaj Siedlarek <msiedla...@nctz.net> wrote: > 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
