[Development] CMake integration and system headers
robertknight at gmail.com
Wed May 7 11:15:57 CEST 2014
> 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
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.
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:
>>> 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
More information about the Development