[Development] CMake integration and system headers

[Mikołaj Siedlarek]

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