MantisBT - CMake
View Issue Details
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.

Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesgz bug_10816_example.tar.gz (477) 2010-06-10 16:25
https://public.kitware.com/Bug/file/3179/bug_10816_example.tar.gz
Issue History
Date ModifiedUsernameFieldChange
2010-06-10 14:38Stingray84New Issue
2010-06-10 14:57Bill HoffmanStatusnew => assigned
2010-06-10 14:57Bill HoffmanAssigned To => Brad King
2010-06-10 15:11Brad KingNote Added: 0020980
2010-06-10 16:25Stingray84File Added: bug_10816_example.tar.gz
2012-08-13 10:44Brad KingStatusassigned => backlog
2012-08-13 10:44Brad KingNote Added: 0030555
2016-06-10 14:28Kitware RobotNote Added: 0041710
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0020980)
Brad King   
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   
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   
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.