[Development] CMake integration and system headers

Kurt Pattyn pattyn.kurt at gmail.com
Wed May 7 13:23:50 CEST 2014



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?
That is of course the ideal way. A number of developers, including myself, are already looking to remove warnings from the public facing API of Qt. But this takes time. In the mean time, treating those headers as system headers lets developers build their applications with the -Werror flag.
As I understand it, these headers will not be added per default. One would still need the include-directories(SYSTEM) directive. Is that correct Mikolaj?
> 
> 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.
> 
> 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



More information about the Development mailing list