View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010816CMakeCMakepublic2010-06-10 14:382016-06-10 14:31
ReporterStingray84 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010816: Adding out of tree dependencies are broken because of relative vs. absolute paths
DescriptionIt took me a while to figure out what was going on, but it turns out that sometimes the generated Makefile targets don't get created properly when using out of tree dependencies. Here's the situation. I have a project (say A) that needs to use a library that's generated from an external CMake project (externB). So, in my CMakeLists.txt for A, I have:

set(EXTERNAL_BUILD_DIR ${PROJECT_SOURCE_DIR}/external/ )

add_subdirectory(../../../externB ${EXTERNAL_BUILD_DIR}/externB)

add_executable(A A.cc)
target_link_libraries(A externB)

Now, if I build A in a "build" directory.
mkdir build
cmake ..
make

I get an error similar to:
*** No rule to make target `../external/externB/CMakeFiles/externB.dir/all', needed by `CMakeFiles/A.dir/all'. Stop.

After looking around in the generated Makefiles, I found out that this occurs because the target:
`../external/externB/CMakeFiles/externB.dir/all' is generated with the name:
`{absolute_path}/external/externB/MakeFiles/externB.dir/all'

So, to solve this, I needed to change:
set(EXTERNAL_BUILD_DIR ${PROJECT_SOURCE_DIR}/external/ )
 to:
set(EXTERNAL_BUILD_DIR ${PROJECT_BINARY_DIR}/external/ )

But, this means that if for some reason you want the out-of-tree source to build somewhere else that's not in the binary tree, CMake will generate the wrong Makefile targets and fail.

TagsNo tags attached.
Attached Filesgz file icon bug_10816_example.tar.gz [^] (477 bytes) 2010-06-10 16:25

 Relationships

  Notes
(0020980)
Brad King (manager)
2010-06-10 15:11

 CMake's "OutOfSource" test has a case of a sub-source and sub-build tree that are both outside the source and build tree of the project. It passes everywhere.

Something is different about this case. Please attach a minimal but complete example in a tarball.
(0030555)
Brad King (manager)
2012-08-13 10:44

 Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

 http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.
(0041710)
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.

 Issue History
Date Modified Username Field Change
2010-06-10 14:38 Stingray84 New Issue
2010-06-10 14:57 Bill Hoffman Status new => assigned
2010-06-10 14:57 Bill Hoffman Assigned To => Brad King
2010-06-10 15:11 Brad King Note Added: 0020980
2010-06-10 16:25 Stingray84 File Added: bug_10816_example.tar.gz
2012-08-13 10:44 Brad King Status assigned => backlog
2012-08-13 10:44 Brad King Note Added: 0030555
2016-06-10 14:28 Kitware Robot Note Added: 0041710
2016-06-10 14:28 Kitware Robot Status backlog => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team