View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0016053CMakeCMakepublic2016-04-07 11:262016-06-10 14:21
ReporterGuillaume Dumont 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformWindowsOSWindowsOS Version10
Product VersionCMake 3.5 
Target VersionFixed in Version 
Summary0016053: $<SHELL_PATH:...> should return a short path on Windows when containing spaces
DescriptionI am trying to build OpenCV from sources using MSVC and the Ninja Generator and I have a failing build because of linker flags added to the target_link_libraries. OpenCV's CMakeLists.txt uses this line of CMake code:

set(OPENCV_LINKER_LIBS ${OPENCV_LINKER_LIBS} -L${p})

OPENCV_LINKER_LIBS is passed to target_link_libraries afterwards. The problem with this line is that it does not work on Windows with the Ninja generator. I tried:

set(OPENCV_LINKER_LIBS ${OPENCV_LINKER_LIBS} ${CMAKE_LIBRARY_PATH_FLAG}$<SHELL_PATH:${p}>)

but that does not work either because the even though we end up using /LIBPATH: instead of /L and backslashes instead of forward slashes the path contains spaces and ninja throws a link error.

Shouldn't SHELL_PATH return a short path, or a path between quotes when the path contains spaces on Windows?
Steps To ReproduceTry to build OpenCV 3.1.0 on Windows with Ninja.
Additional InformationSee OpenCV issue: https://github.com/Itseez/opencv/issues/6372 [^]
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0040823)
Brad King (manager)
2016-04-07 11:46

 The purpose of SHELL_PATH is to convert drive letters and slashes. It is not to produce a fully quoted/escaped/etc. path for use on a command line. Typically it is used in a context that has proper escaping done later. Flags given to target_link_libraries is not such a context (for historical reasons).

I'm not familiar with OpenCV's use case but there must be another solution. The -L option is for link directories, and we already have a command for that. CMake encourages use of full paths to libraries so linker search directories are rarely needed.
(0040824)
Guillaume Dumont (reporter)
2016-04-07 12:18

 Thanks for answering. I understand that SHELL_PATH was not intended for this use case.

I think OpenCV's use case is to avoid having dependencies to CUDA libraries as an absolute path in the exported targets file so that the package remains relocatable. I assuming that since they extract the libraries name for the paths returned by FindCuda.cmake and add their directory to the link_directories command.

I guess the recommended way would be to export the library names with the full path to libraries. But this is sub-optimal since the package could be relocated anymore?

Or, convert CUDA libraries to imported targets and distribute an appropriately modified FindCuda module with the package?
(0040825)
Brad King (manager)
2016-04-07 14:25

 Re 0016053:0040824: Yes, having imported target names as the exported dependencies is a good approach. Of course it is up to their package configuration file to ensure that the imported targets are again made available in the client configuration.
(0041199)
Kitware Robot (administrator)
2016-06-10 14:21

 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
2016-04-07 11:26 Guillaume Dumont New Issue
2016-04-07 11:46 Brad King Note Added: 0040823
2016-04-07 11:46 Brad King Status new => resolved
2016-04-07 11:46 Brad King Resolution open => no change required
2016-04-07 12:18 Guillaume Dumont Note Added: 0040824
2016-04-07 14:25 Brad King Note Added: 0040825
2016-06-10 14:21 Kitware Robot Note Added: 0041199
2016-06-10 14:21 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team