(0035319)
Stephen Kelly (developer)
2014-03-05 16:16

Allowing IMPORTED targets as the lhs of target_include_directories was considered, implemented and reverted before, but I don't recall why.

I think the only option that works for you in the future will be linking OBJECT libraries to things.

(0035325)
Brad King (manager)
2014-03-06 10:42

This is somewhat the opposite of 0014751. Here we want to get all usage requirements except linking. More specifically, the implementation of the OBJECT library needs compilation usage requirements but consumers of the object library need linking usage requirements.

(0038011)
Ben Boeckel (developer)
2015-02-20 15:59

I'm nominating this for 3.3. I need this sooner rather than later. I'll try to take a whack at it.

(0038012)
Ben Boeckel (developer)
2015-02-20 17:34

@Steven: so I have LHS implemented; working on RHS now. I see no test errors for it (after updating the LHS test to check for the right thing). Are the original commits around somewhere?

(0038014)
Stephen Kelly (developer)
2015-02-21 04:13

Ben, see

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cfe4f1b76 [^]
Allow target_link_libraries with IMPORTED targets.

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48a4cf21 [^]
Revert "Allow target_link_libraries with IMPORTED targets."

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b98d14d4 [^]
Disallow porcelain to populate includes and defines of IMPORTED targets.

However, I don't think those are actually relevant to this feature request. It was a response to the IMPORTED libraries mention in the summary. If you're implementing things as Brad wrote in 0014778:0035325, I don't think they're relevant.

(0039208)
Vladimír Vondruš (reporter)
2015-07-31 05:24

Hello, any progress on this? I wanted to switch to IMPORTED targets from the old ${variable} way, but I have a lot of OBJECT libs for which I need to specify include directories etc. and target_link_libraries() seems to me like the most intuitive way to do it.

The current workaround is unnecessarily verbose.

target_include_directories(Example PRIVATE $<TARGET_PROPERTY:Qt5::Core,INTERFACE_INCLUDE_DIRECTORIES>)
target_compile_definitions(Example PRIVATE $<TARGET_PROPERTY:Qt5::Core,INTERFACE_COMPILE_DEFINITIONS>)

(0040142)
Damien Buhl (reporter)
2016-01-05 09:30

Thanks for the workaround, yes it's sad that we cannot do this.

I also needed to take the INTERFACE_COMPILE_OPTIONS which are sometimes used (like C++11 flags).
target_compile_options(SAUTER_CONTROL_CORE_OBJECT_FILES_WITHOUT_MAIN PRIVATE $<TARGET_PROPERTY:lib-cpp-slc::cpp-slc,INTERFACE_COMPILE_OPTIONS>)

(0042495)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2014-02-28 02:40	A. Klitzing	New Issue
2014-03-05 16:16	Stephen Kelly	Note Added: 0035319
2014-03-05 16:16	Stephen Kelly	Summary	Allow IMPORTED target in target_include_directories => Allow linking OBJECT libraries for usage requirements.
2014-03-06 10:39	Brad King	Relationship added	related to 0014751
2014-03-06 10:42	Brad King	Note Added: 0035325
2015-02-20 15:59	Ben Boeckel	Assigned To	=> Ben Boeckel
2015-02-20 15:59	Ben Boeckel	Status	new => assigned
2015-02-20 15:59	Ben Boeckel	Note Added: 0038011
2015-02-20 15:59	Ben Boeckel	Target Version	=> CMake 3.3
2015-02-20 17:34	Ben Boeckel	Note Added: 0038012
2015-02-21 04:13	Stephen Kelly	Note Added: 0038014
2015-04-22 09:55	Brad King	Target Version	CMake 3.3 =>
2015-07-31 05:24	Vladimír Vondruš	Note Added: 0039208
2016-01-05 09:30	Damien Buhl	Note Added: 0040142
2016-06-10 14:29	Kitware Robot	Note Added: 0042495
2016-06-10 14:29	Kitware Robot	Status	assigned => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0035319) Stephen Kelly (developer) 2014-03-05 16:16	Allowing IMPORTED targets as the lhs of target_include_directories was considered, implemented and reverted before, but I don't recall why. I think the only option that works for you in the future will be linking OBJECT libraries to things.

(0035325) Brad King (manager) 2014-03-06 10:42	This is somewhat the opposite of 0014751. Here we want to get all usage requirements except linking. More specifically, the implementation of the OBJECT library needs compilation usage requirements but consumers of the object library need linking usage requirements.

(0038011) Ben Boeckel (developer) 2015-02-20 15:59	I'm nominating this for 3.3. I need this sooner rather than later. I'll try to take a whack at it.

(0038012) Ben Boeckel (developer) 2015-02-20 17:34	@Steven: so I have LHS implemented; working on RHS now. I see no test errors for it (after updating the LHS test to check for the right thing). Are the original commits around somewhere?

(0038014) Stephen Kelly (developer) 2015-02-21 04:13	Ben, see http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cfe4f1b76 [^] Allow target_link_libraries with IMPORTED targets. http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48a4cf21 [^] Revert "Allow target_link_libraries with IMPORTED targets." http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b98d14d4 [^] Disallow porcelain to populate includes and defines of IMPORTED targets. However, I don't think those are actually relevant to this feature request. It was a response to the IMPORTED libraries mention in the summary. If you're implementing things as Brad wrote in 0014778:0035325, I don't think they're relevant.

(0039208) Vladimír Vondruš (reporter) 2015-07-31 05:24	Hello, any progress on this? I wanted to switch to IMPORTED targets from the old ${variable} way, but I have a lot of OBJECT libs for which I need to specify include directories etc. and target_link_libraries() seems to me like the most intuitive way to do it. The current workaround is unnecessarily verbose. target_include_directories(Example PRIVATE $<TARGET_PROPERTY:Qt5::Core,INTERFACE_INCLUDE_DIRECTORIES>) target_compile_definitions(Example PRIVATE $<TARGET_PROPERTY:Qt5::Core,INTERFACE_COMPILE_DEFINITIONS>)

(0040142) Damien Buhl (reporter) 2016-01-05 09:30	Thanks for the workaround, yes it's sad that we cannot do this. I also needed to take the INTERFACE_COMPILE_OPTIONS which are sometimes used (like C++11 flags). target_compile_options(SAUTER_CONTROL_CORE_OBJECT_FILES_WITHOUT_MAIN PRIVATE $<TARGET_PROPERTY:lib-cpp-slc::cpp-slc,INTERFACE_COMPILE_OPTIONS>)

(0042495) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.