[CMake] TGZ installer following links

[John R. Cary]

Attached is a minimal standalone example that illustrates the problem.

If build dir is next to the directory resulting from untarring this, do

cmake -DCMAKE_INSTALL_PREFIX=$HOME/tmp/cmtprefix ../cmt
make all install
# You will see that in the installation, the top cmtdir is a link:
numbersix.cary$ ls -l $HOME/tmp/cmtprefix/cmtdir
lrwxrwxr-x  1 cary  research  10 Jun 17 11:16 
/Users/cary/tmp/cmtprefix/cmtdir -> bin/cmtdir
# then do
make package
tar xzf cmt-1.1.1-Darwin.tar.gz
# and you will see that the top-level cmtdir is a directory:
numbersix.cary$ ls -l cmt-1.1.1-Darwin
total 0
drwxrwxr-x  3 cary  research  102 Jun 17 11:25 bin
drwxrwxr-x  3 cary  research  102 Jun 17 11:25 cmtdir

such that two copies of the binary are installed.

Thanks for your help!

John Cary


On 6/17/11 9:43 AM, Eric Noulard wrote:
> 2011/6/17 John R. Cary<cary at txcorp.com>:
>> I just found another person who had the same problem:
>>
>> http://www.cmake.org/pipermail/cmake/2007-July/015024.html
>>
>> Does not look like there was ever a response to this?
> Yes you seem right now back in 2007 CPack TGZ wasn't using the same
> method to package TGZ.. but keep reading
>
>> On 6/17/11 8:46 AM, John R. Cary wrote:
>>> On 6/16/11 2:15 PM, Eric Noulard wrote:
>>>> I never used install(CODE ... but besides that this should work.
>>>> did you have a look at the symlinks found in the CPack temp install dir:
>>>>
>>>> _CPack_Packages/<xxx>/TGZ/<yyy>
>>>>
>>>> are they local as they should be or are they pointing to some absolute
>>>> path.
>>> They are correct in the directory:
>>>
>>> octet.cary$ pwd
>>>
>>> /home/research/cary/projects/composerall/builds/vorpalcomposer/ser/_CPack_Packages/Linux/TGZ
>>> octet.cary$ ls -ls
>>> vorpal-4.3.0-r17099-composer-r452-Linux-x86_64.orig/Contents/
>>> total 24
>>> 0 lrwxrwxrwx 1 cary research   13 2011-06-17 04:31 current ->  Foo/current
>>> 4 drwxrwsr-x 4 cary research 4096 2011-06-17 04:31 Foo
>>> octet.cary$
>>>
>>> as links, but untarring the tarball shows that they were tarred as
>>> directories,
>>>
>>> octet.cary$ ls -ls
>>> vorpal-4.3.0-r17099-composer-r452-Linux-x86_64/Contents/
>>> total 32
>>> 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:39 current
>>> 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:38 Foo
>>>
>>> as if tar had been called with '-h'.
>>>
>>> Does CPack use tar?   Is there any way to control the options that
>>> the tarring code is called with?
> No it does not use tar.
> CPack is using libarchive (http://code.google.com/p/libarchive/)
> [in fact there is a copy of libarchive inside cmake source).
>
> For TAR based archive (TGZ, TBZ2) the "restricted pax" is used:
> http://code.google.com/p/libarchive/wiki/ManPageLibarchiveFormats5
>
> Moreover as noted before I do generate TGZ which includes symlinks without
> trouble so there must be something different in your case.
>
> Could you provide us a standalone minimal test case which exhibit the problem?
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmt.tgz
Type: application/x-gzip
Size: 828 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110617/20286e68/attachment.bin>