|
Notes |
|
|
(0037325)
|
|
Brad King
|
|
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
|
|
2014-12-01 15:13
|
|
|
The same thought came to my mind, but doesn't that affect ordering of libraries too? |
|
|
|
(0037344)
|
|
Brad King
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
2015-05-21 10:14
|
|
|
|
|
(0042675)
|
|
Kitware Robot
|
|
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. |
|