View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0011392 | CMake | CMake | public | 2010-11-02 11:48 | 2016-06-10 14:31 | ||||
Reporter | Derek Bruening | ||||||||
Assigned To | Kitware Robot | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-8 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0011392: find_package does not support relative paths | ||||||||
Description | I have one CMake project ("drmemory") that uses another ("DynamoRIO") via find_package, using a cache variable "DynamoRIO_DIR" to point at the location of the DynamoRIO config file. It is very natural to use a relative path from the build dir at configure time for DynamoRIO_DIR. However, this does not always work. Try this on Linux with any CMake version (I've tried 2.6.4 and 2.8.0) and you'll get a find_package failure on the config for drmemory: mkdir test-dotdot cd test-dotdot svn checkout -r 474 http://dynamorio.googlecode.com/svn/trunk/ [^] dynamorio mkdir -p build-dynamorio/sub cd build-dynamorio/sub CXXFLAGS=-m32 CFLAGS=-m32 cmake -DBUILD_DOCS=OFF -DCMAKE_INSTALL_PREFIX=../../exports ../../dynamorio && make -j4 install cd ../.. svn checkout -r 75 http://drmemory.googlecode.com/svn/trunk/ [^] drmemory mkdir -p build-drmemory/sub cd build-drmemory/sub ls ../../exports/cmake CXXFLAGS=-m32 CFLAGS=-m32 cmake -DDynamoRIO_DIR=../../exports/cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=../../exports_drmemory ../../drmemory I asked Brad King about this: By the time find_package runs it has no clue what the base path was for the relative path. The best guess it has is the *source* tree containing the CMakeLists.txt that invoked it. This behavior is meant for finding in-tree packages. We've never supported relative paths here. The command line parser has no way to know that DynamoRIO_DIR is a path and not a string and therefore cannot do conversion to full path safely. Someday we will have a way to map options like --prefix= to cache definitions that have types. That mapping might be able to do this. At the least, the find_package documentation should state that relative paths are not supported, or what they are relative to. My intuition says that a relative path would be from the build dir. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0041760) Kitware Robot (administrator) 2016-06-10 14:28 |
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. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2010-11-02 11:48 | Derek Bruening | New Issue | |
2010-12-15 12:12 | David Cole | Assigned To | => Brad King |
2010-12-15 12:12 | David Cole | Status | new => assigned |
2011-09-19 10:21 | Brad King | Assigned To | Brad King => |
2011-09-19 10:21 | Brad King | Status | assigned => backlog |
2016-06-10 14:28 | Kitware Robot | Note Added: 0041760 | |
2016-06-10 14:28 | Kitware Robot | Status | backlog => resolved |
2016-06-10 14:28 | Kitware Robot | Resolution | open => moved |
2016-06-10 14:28 | Kitware Robot | Assigned To | => Kitware Robot |
2016-06-10 14:31 | Kitware Robot | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |