MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010096CMakeCPackpublic2010-01-05 17:232011-01-18 16:34
ReporterDerek Bruening 
Assigned ToBill Hoffman 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in VersionCMake 2.8.3 
Summary0010096: cpack does not preserve symlinks in CPACK_INSTALLED_DIRECTORIES
DescriptionWhen incorporating files external to a project into a package I use CPACK_INSTALLED_DIRECTORIES. However, it de-references symbolic links, resulting in duplicate files and wasted space in the final package.

I tested with cmake-2.8.0-rc2-Linux-i386 and it has the same behavior.

Xref case 5430 about a similar problem but with source packages.

I don't see a file() or other command to create a symbolic link so I don't have a good workaround for this.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005430closed Eric NOULARD cpack does not preserve symbolic links in the source distribution tarball 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-01-05 17:23Derek BrueningNew Issue
2010-01-13 10:44bobkuehneNote Added: 0019115
2010-07-26 07:35Eric NOULARDRelationship addedrelated to 0005430
2010-07-29 08:45Eric NOULARDNote Added: 0021539
2010-07-29 08:45Eric NOULARDStatusnew => assigned
2010-07-29 08:45Eric NOULARDAssigned To => Bill Hoffman
2010-07-29 08:46Eric NOULARDNote Added: 0021540
2011-01-18 16:34Eric NOULARDNote Added: 0024899
2011-01-18 16:34Eric NOULARDStatusassigned => closed
2011-01-18 16:34Eric NOULARDResolutionopen => fixed
2011-01-18 16:34Eric NOULARDFixed in Version => CMake 2.8.3

Notes
(0019115)
bobkuehne   
2010-01-13 10:44   
i'd raise the priority on this *quite* a bit - it effectively means cmake packaging for linux versions is impossible. my c++ application now breaks entirely when it runs, due to the library symlink conventions on unix. for example, libfoo.so typically links to libfoo.so.1, which in turn links to the real version, libfoo.so.20.3.1. the app then resolves its link to one of those, and with the links missing, a failure at runtime occurs.
(0021539)
Eric NOULARD   
2010-07-29 08:45   
I did propose a patch for 5430.
I think the two bugs may be closed together if the patch is accepted.
(0021540)
Eric NOULARD   
2010-07-29 08:46   
Bill,

I did assign the bug to you too because if 5430 is closed
this one should be too.
(0024899)
Eric NOULARD   
2011-01-18 16:34   
Closed with its sibling/related bug 5430