MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011153CMakeCMakepublic2010-08-19 17:182013-10-07 10:03
ReporterClausKlein 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0011153: cmake out of source build writes build files at source dirs
Description I discovered than in the special case of a substituted PROJECT_SOURCE_DIR,
all build files for subdir packages are created in PROJECT_SOURCE_DIR and not at the PROJECT_BINARY_DIR.

I use windows XP cmd shell
     subst w: z:/some/deep/path/to/source/dir

Than I create a new build dir:

cd /d w:/
mkdir build
cd build
cmake ..


after that, all subdirs of the source dir are created as
w:/build<subdir1>
w:/build<subdir2>
...
filled with the cmake build files.

I tested cmake 2.8.0, 2.8.1 and 2.8.2 version. all have the same behaviour!
The created project builds fine too.

It seems that the PROJECT_BINARY_DIR and the subdir paths are concatenated without a path separator.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0010072closed Brad King invalid binary path if makefile in root directory 
related to 0010994closed Brad King Windows: find_* commands can find paths with no drive letter 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-08-19 17:18ClausKleinNew Issue
2010-08-23 11:22Brad KingNote Added: 0021894
2010-12-08 08:23David ColeAssigned To => David Cole
2010-12-08 08:23David ColeStatusnew => assigned
2010-12-08 08:23David ColeNote Added: 0023793
2010-12-17 07:41David ColeTarget Version => CMake 2.8.4
2011-01-03 17:35Bill HoffmanNote Added: 0024371
2011-01-04 16:50ClausKleinNote Added: 0024402
2011-01-04 17:20Bill HoffmanNote Added: 0024403
2011-01-04 17:46David ColeNote Added: 0024404
2011-01-04 17:52David ColeNote Added: 0024405
2011-01-05 12:46David ColeNote Added: 0024428
2011-01-05 12:46David ColeTarget VersionCMake 2.8.4 =>
2011-01-05 19:26David ColeRelationship addedrelated to 0010994
2011-10-25 22:53David ColeAssigned ToDavid Cole =>
2011-10-25 22:53David ColeStatusassigned => backlog
2012-01-18 16:10Patrick SpendrinNote Added: 0028358
2013-03-08 08:03Brad KingRelationship addedduplicate of 0010072
2013-03-08 08:05Brad KingNote Added: 0032537
2013-03-08 08:05Brad KingStatusbacklog => resolved
2013-03-08 08:05Brad KingResolutionopen => duplicate
2013-10-07 10:03Robert MaynardNote Added: 0033983
2013-10-07 10:03Robert MaynardStatusresolved => closed

Notes
(0021894)
Brad King   
2010-08-23 11:22   
This commit may address the problem:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a21abd6 [^]
(0023793)
David Cole   
2010-12-08 08:23   
Does CMake 2.8.3 have the same issue?

Did Brad's referenced commit in the previous note fix this?

Thanks,
David
(0024371)
Bill Hoffman   
2011-01-03 17:35   
Is this still an issue?
(0024402)
ClausKlein   
2011-01-04 16:50   
Yes this is still an issue, tested with CMake 2.8.3 on Windows XP
(0024403)
Bill Hoffman   
2011-01-04 17:20   
Hmm, sounds like cmake does not like the subst command. I am not even sure how one would add support for something like that...
(0024404)
David Cole   
2011-01-04 17:46   
This has nothing to do with "subst" per se, and everything to do with the combination of: a CMakeLists.txt at the root of a Windows drive letter, and add_subdirectory calls in that CMakeLists file.

Easily reproducible with putting a CMake-based source tree at the root of any Windows drive...
(0024405)
David Cole   
2011-01-04 17:52   
The easy workaround, of course, is to put your source tree in a directory named "s" and map it such that the full path to the source tree is "w:/s"

That should avoid the problem. (At least, it did for me, when I backed up one level on the subst-ing...)
(0024428)
David Cole   
2011-01-05 12:46   
Unsetting the target version field. Since there is an easy workaround, and plenty of other more important bugs to try to finish for the 2.8.4 release, this one is: deferred until later.
(0028358)
Patrick Spendrin   
2012-01-18 16:10   
A duplicate of this bug: http://public.kitware.com/Bug/view.php?id=10072 [^]
(0032537)
Brad King   
2013-03-08 08:05   
Resolving as duplicate of 0010072.
(0033983)
Robert Maynard   
2013-10-07 10:03   
Closing resolved issues that have not been updated in more than 4 months.