View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012879CMakeCMakepublic2012-01-17 20:332012-07-09 06:52
ReporterThomas Fischer 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
Platformx86OSwindow7OS Versionx64
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0012879: fix: allow absolute paths in IMPORTED_LOCATION with full filename under windows
Descriptionthe attached patch will allow to use full paths for imported libs for the VS2010 generator, like this:

SET_PROPERTY(TARGET ${libName} PROPERTY IMPORTED_LOCATION_RELEASE ${ROR_DEPENDENCIES_DIR}/libs/${ARCH_DIR}/${dirName}/Release/${libName}.lib)
Steps To Reproducesince this is a shortcoming that treads every _LOCATION as path, it will always reproduce
Additional Informationi was not able to get VisualStudio to link correctly with the unpatched code. The new code will check before assuming if its a directory (FileIsDirectory) so no harm done there.

escaping paths and filenames for windows also always work, even when no '/' or '\' are in the filename.
TagsNo tags attached.
Attached Filespatch file icon cmake-lib-import.patch [^] (984 bytes) 2012-01-17 20:33 [Show Content]

 Relationships

  Notes
(0028348)
Brad King (manager)
2012-01-18 08:26

 The IMPORTED_LOCATION has always been intended for specifying the full path to a library including the file name. That is why the "isPath" argument of the item is hard-coded to true. It works as documented in all generators and is extensively tested by the test suite.

What is your use case that fails?
(0028361)
Thomas Fischer (reporter)
2012-01-19 06:14
edited on: 2012-01-19 06:14

 interesting, i see. So it must be some other problem i added to the system that it fails to link properly.

so, i debugged further, and it seems the path conversion might be using a wrong argument as path that should be related.

my observations so far:
the path of the lib is found correctly by cmake. see screen 1 as reference where it starts to make the path relative for usage in VS:
http://modclub.rigsofrods.com/thomas/one.png [^]

which results ultimately in this conversion in screen 2:
http://modclub.rigsofrods.com/thomas/two.png [^]

so, configured and generated VS2010 project. After compilation, the linker is unable to find the specified libraries: "4>LINK : fatal error LNK1104: cannot open file '..\..\..\dependencies\libs\x86\Ogre\Release\OgreMain.lib'
"

i dont know how to find out the current working path of the linker. Using absolute paths, which my patch actually does, it works. With relative paths, not.

all the sources i am testing with are online:
http://redmine.rigsofrods.com/projects/ror/repository/show/trunk [^]
or
http://rigsofrods.svn.sourceforge.net/viewvc/rigsofrods/trunk/ [^]

thanks for your support!
(0028362)
Brad King (manager)
2012-01-19 09:58

 I don't think this has anything specifically to do with IMPORTED_LOCATION. It's CMake's conversion of the path to a relative format. This is a widely used feature so there must be something subtle in this case.

The converted path should be relative to the location of the .vcxproj file. Is it correct?

CMake is unwilling to construct a relative path with enough '../' pieces to leave the build directory (or source dir if build is under the source). If you try a purely out-of-source build the generated build files should use a full path. Does that work as expected?

I tried building your sources but the dependencies I downloaded from

 http://cdnetworks-us-2.dl.sourceforge.net/project/rigsofrods/rigsofrods/0.39-dev/ror-dependencies-18.zip [^]

do not seem to have the expected include directory layout (includes/x86/ expected, include/ present). Where can I get the dependencies that match trunk?
(0028386)
Thomas Fischer (reporter)
2012-01-20 15:40

 > I don't think this has anything specifically to do with IMPORTED_LOCATION. It's CMake's conversion of the path to a relative format. This is a widely used feature so there must be something subtle in this case.
yes, i am afraid as well i made a huge mistake and waste your time ;)

> The converted path should be relative to the location of the .vcxproj file. Is it correct?
indeed, should be i think

> CMake is unwilling to construct a relative path with enough '../' pieces to leave the build directory (or source dir if build is under the source). If you try a purely out-of-source build the generated build files should use a full path. Does that work as expected?
ah, never knew. will test now :)

my first tests resulted in correct settings, so seems to work well from a first glance.

> I tried building your sources but the dependencies I downloaded from
 http://cdnetworks-us-2.dl.sourceforge.net/project/rigsofrods/rigsofrods/0.39-dev/ror-dependencies-18.zip [^]
> do not seem to have the expected include directory layout (includes/x86/ expected, include/ present). Where can I get the dependencies that match trunk?

sorry i wasnt actually expecting that you download and try this - thanks for helping us :)
i have uploaded my latest zip there:
http://sourceforge.net/projects/rigsofrods/files/rigsofrods/0.39-dev/ror-dependencies-19.zip/download [^]

i contains binaries for Debug,RelWithDebug,Release configurations on the x86 architecture compiled with VS2010-SP1

be warned: its not working yet. I still have to improve/fix our cmake buildsystem to properly use these precompiled binaries. This is WIP :-/
like the lib finding of wxWidgets and boost will not work.
(0028391)
Thomas Fischer (reporter)
2012-01-23 08:20

 for whatever reason, it works now. Sorry that i wasted your time :(

maybe i can work on another patch that ignores the result code of commands for add_custom_command?

http://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_custom_command [^]

since i need that when copying files around with xcopy (cmake -E copy will not work due to missing wildcard support)
(0028392)
Brad King (manager)
2012-01-23 09:08

 > for whatever reason

Great. I'm resolving this issue as "no change required" with regard to IMPORTED_LOCATION and relative path conversion. Other topics can be brought up on the mailing list if you want further discussion with a broader audience.

> cmake -E copy will not work due to missing wildcard support

You could consider using cmake -P to run a customized .cmake script that uses the file(COPY) command.
(0029960)
David Cole (manager)
2012-07-09 06:52

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-01-17 20:33 Thomas Fischer New Issue
2012-01-17 20:33 Thomas Fischer File Added: cmake-lib-import.patch
2012-01-18 08:26 Brad King Note Added: 0028348
2012-01-19 06:14 Thomas Fischer Note Added: 0028361
2012-01-19 06:14 Thomas Fischer Note Edited: 0028361
2012-01-19 09:58 Brad King Note Added: 0028362
2012-01-20 15:40 Thomas Fischer Note Added: 0028386
2012-01-23 08:20 Thomas Fischer Note Added: 0028391
2012-01-23 09:08 Brad King Note Added: 0028392
2012-01-23 09:08 Brad King Status new => resolved
2012-01-23 09:08 Brad King Resolution open => no change required
2012-01-23 09:08 Brad King Assigned To => Brad King
2012-07-09 06:52 David Cole Note Added: 0029960
2012-07-09 06:52 David Cole Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team