[cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes
Matthew Woehlke
matthew.woehlke at kitware.com
Thu Jul 25 13:45:00 EDT 2013
On 2013-07-25 13:25, Stephen Kelly wrote:
> Brad King wrote:
>
>> On 07/25/2013 12:22 PM, Stephen Kelly wrote:
>>> library A should have a unit test which attempts to compile all
>>> of its headers with all warnings enabled. In Qt every module has a
>>> 'headersclean' unit test which does exactly that.
>>
>> While this is a good idea we're not going to assume every project has
>> such discipline. Also some consumers may include headers with a
>> different preprocessing context that exposes the warning.
>
> Right. Even if all headers are used by the upstream itself, this still
> applies. However, I still think IMPORTED=SYSTEM by *default* is a good idea,
> and let the edge case switch it back. I'm not seeing support for it though,
> so I guess I'll drop it.
Somewhat echoing Brad's reply here, but it's not that I'm opposed to the
idea, merely "concerned" that it is possible to get non-system includes
when that is desired.
Perhaps that is a misreading on my part, but I was getting the
impression this change would make it so that imported targets can only
ever be SYSTEM.
>> Then why not make INTERFACE_SYSTEM_INCLUDE_DIRECTORIES the default in
>> the Qt imported targets and have a switch to turn them off? The code
>>
>> set(QT_INCLUDE_DIRS_NO_SYSTEM 1)
>> find_package(Qt5Core)
>>
>> is not so bad in the edge case that needs it.
>
> I don't like it though :). I'd prefer not to have any variables that change
> the behavior of a find_package call, so that only one find_package is ever
> needed, not multiple in different directories for scope.
FWIW, I agree; variables controlling find_package (except search paths)
are almost always an inferior solution :-).
That said... what about having a SYSTEM (and/or NO_SYSTEM) flag for
find_package? This could, for config-based packages with imported
targets, control the default behavior for imported include directories.
>> Either way, the tll() SYSTEM option could still be useful.
>
> I'll add that tomorrow.
Again FWIW, a nice advantage of this is the ability to specify SYSTEM
includes per target. (I'm not sure why you'd want to build one target
with imported includes as SYSTEM and another not, but you could...)
--
Matthew
More information about the cmake-developers
mailing list