[Development] CMake integration and system headers

[Robert Knight]

> 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 <msiedlarek at nctz.net> wrote:
> On 07 May 2014, at 11:15, Robert Knight <robertknight at 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 <msiedlarek at nctz.net> wrote:
>>> On 07 May 2014, at 10:59, Kurt Pattyn <pattyn.kurt at gmail.com> wrote:
>>>> On 06 May 2014, at 11:40, Mikołaj Siedlarek <msiedlarek at 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 at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>