(0037325)
Brad King (manager)
2014-12-01 09:58

Hmm. If only a library name is available and a path is not then the imported target should instead be an INTERFACE library with the INTERFACE_LINK_LIBRARIES set to the library name.

(0037343)
Stephen Kelly (developer)
2014-12-01 15:13

The same thought came to my mind, but doesn't that affect ordering of libraries too?

(0037344)
Brad King (manager)
2014-12-01 15:28

Re 0015267:0037343: Yes. It looks like we need a way for an imported library to be linked by '-lfoo' (on UNIX) or 'foo.lib' (on MS tools).

As discussed for a similar issue in Qt5 dependencies, I do not think we can reliably find the actual 'opengl32' library file, so we need to go with just the logical name even for the imported target.

(0037345)
Philipp Möller (reporter)
2014-12-01 15:48

I'm not very familiar with Windows and I expected this to work. Since the value of OPENGL_gl_LIBRARY is accepted as is by target_link_libraries. It would be very inconvenient if code creating imported targets needs to add a special case for this although I'm not sure how common this case is at all.

(0037346)
Brad King (manager)
2014-12-01 15:54

Re 0015267:0037345: IMPORTED_LOCATION is documented as taking a full path only, and target_link_libraries documents that it can accept a full path or a name. Imported targets were originally designed to be the result of exporting a CMake-built project target, when a valid IMPORTED_LOCATION full path is always available.

More infrastructure is needed in CMake to support the name-only case.

(0037347)
Philipp Möller (reporter)
2014-12-01 16:02

To me the best solution would be to either

- increase the symmetry between IMPORTED_LOCATION and the library arguments of target_link_libraries
- make a selection of target_* commands available for IMPORTED targets

There is a good use case for creating IMPORTED targets manually (Find files) and direct manipulation of target properties should be reduced to a minimum. In fact, I would much prefer it if target properties would be considered an implementation detail.

(0037348)
Brad King (manager)
2014-12-01 16:09

I hate to have to do this, but we cannot release 3.1 with a feature that is so fundamentally broken on a popular platform. I've reverted it:

FindOpenGL: Revert support for imported targets
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02e34de2 [^]

The feature will have to be built along with the needed infrastructure in post-3.1 development.

(0037349)
Brad King (manager)
2014-12-01 16:24

For reference, this problem does not apply to other find modules that provide imported targets in general because they typically look for non-system libraries that can actually be found on disk.

(0037350)
Philipp Möller (reporter)
2014-12-01 16:52

Alternatively I can provide a patch for this (special casing the target on WIN32) by tomorrow but I do not have the means to test it on a Windows machine.

(0037352)
Brad King (manager)
2014-12-02 08:55

Re 0015267:0037350: The problem is that CMake does not support the kind of imported target we need for this to get in-order linking.

OTOH in the case of OpenGL there should be no dependencies on later libraries so using an INTERFACE library with INTERFACE_LINK_LIBRARIES set to either the full path or the library name may work for now. Then the targets can be upgraded when future infrastructure is available.

However, I'm concerned that this was only discovered prior to the 3.1 release by luck. The reason is that the feature was added without tests. In order to restore the feature, we'll need to add a Tests/FindOpenGL project to test the module and the imported targets, much like Tests/FindGTK2.

(0038790)
Brad King (manager)
2015-05-21 10:14

Relevant mailing list thread:

Importing platform SDK libraries without a full path
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284 [^]

(0042675)
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-11-28 02:44	Nils Gladitz	New Issue
2014-12-01 09:58	Brad King	Note Added: 0037325
2014-12-01 11:39	Brad King	Status	new => acknowledged
2014-12-01 11:39	Brad King	Target Version	=> CMake 3.2
2014-12-01 15:13	Stephen Kelly	Note Added: 0037343
2014-12-01 15:28	Brad King	Note Added: 0037344
2014-12-01 15:48	Philipp Möller	Note Added: 0037345
2014-12-01 15:54	Brad King	Note Added: 0037346
2014-12-01 16:02	Philipp Möller	Note Added: 0037347
2014-12-01 16:09	Brad King	Note Added: 0037348
2014-12-01 16:24	Brad King	Note Added: 0037349
2014-12-01 16:32	Brad King	Status	acknowledged => backlog
2014-12-01 16:32	Brad King	Target Version	CMake 3.2 =>
2014-12-01 16:33	Brad King	Summary	FindOpenGL.cmake imported targets are broken on windows => FindOpenGL: need name-only imported targets on Windows
2014-12-01 16:33	Brad King	Product Version	CMake 3.1 =>
2014-12-01 16:52	Philipp Möller	Note Added: 0037350
2014-12-02 08:55	Brad King	Note Added: 0037352
2015-05-21 10:14	Brad King	Note Added: 0038790
2016-06-10 14:29	Kitware Robot	Note Added: 0042675
2016-06-10 14:29	Kitware Robot	Status	backlog => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0037325) Brad King (manager) 2014-12-01 09:58	Hmm. If only a library name is available and a path is not then the imported target should instead be an INTERFACE library with the INTERFACE_LINK_LIBRARIES set to the library name.

(0037343) Stephen Kelly (developer) 2014-12-01 15:13	The same thought came to my mind, but doesn't that affect ordering of libraries too?

(0037344) Brad King (manager) 2014-12-01 15:28	Re 0015267:0037343: Yes. It looks like we need a way for an imported library to be linked by '-lfoo' (on UNIX) or 'foo.lib' (on MS tools). As discussed for a similar issue in Qt5 dependencies, I do not think we can reliably find the actual 'opengl32' library file, so we need to go with just the logical name even for the imported target.

(0037345) Philipp Möller (reporter) 2014-12-01 15:48	I'm not very familiar with Windows and I expected this to work. Since the value of OPENGL_gl_LIBRARY is accepted as is by target_link_libraries. It would be very inconvenient if code creating imported targets needs to add a special case for this although I'm not sure how common this case is at all.

(0037346) Brad King (manager) 2014-12-01 15:54	Re 0015267:0037345: IMPORTED_LOCATION is documented as taking a full path only, and target_link_libraries documents that it can accept a full path or a name. Imported targets were originally designed to be the result of exporting a CMake-built project target, when a valid IMPORTED_LOCATION full path is always available. More infrastructure is needed in CMake to support the name-only case.

(0037347) Philipp Möller (reporter) 2014-12-01 16:02	To me the best solution would be to either - increase the symmetry between IMPORTED_LOCATION and the library arguments of target_link_libraries - make a selection of target_* commands available for IMPORTED targets There is a good use case for creating IMPORTED targets manually (Find files) and direct manipulation of target properties should be reduced to a minimum. In fact, I would much prefer it if target properties would be considered an implementation detail.

(0037348) Brad King (manager) 2014-12-01 16:09	I hate to have to do this, but we cannot release 3.1 with a feature that is so fundamentally broken on a popular platform. I've reverted it: FindOpenGL: Revert support for imported targets http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02e34de2 [^] The feature will have to be built along with the needed infrastructure in post-3.1 development.

(0037349) Brad King (manager) 2014-12-01 16:24	For reference, this problem does not apply to other find modules that provide imported targets in general because they typically look for non-system libraries that can actually be found on disk.

(0037350) Philipp Möller (reporter) 2014-12-01 16:52	Alternatively I can provide a patch for this (special casing the target on WIN32) by tomorrow but I do not have the means to test it on a Windows machine.

(0037352) Brad King (manager) 2014-12-02 08:55	Re 0015267:0037350: The problem is that CMake does not support the kind of imported target we need for this to get in-order linking. OTOH in the case of OpenGL there should be no dependencies on later libraries so using an INTERFACE library with INTERFACE_LINK_LIBRARIES set to either the full path or the library name may work for now. Then the targets can be upgraded when future infrastructure is available. However, I'm concerned that this was only discovered prior to the 3.1 release by luck. The reason is that the feature was added without tests. In order to restore the feature, we'll need to add a Tests/FindOpenGL project to test the module and the imported targets, much like Tests/FindGTK2.

(0038790) Brad King (manager) 2015-05-21 10:14	Relevant mailing list thread: Importing platform SDK libraries without a full path http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284 [^]

(0042675) 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.

Relationships