MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013019CMakeCPackpublic2012-03-06 10:002016-06-10 14:31
ReporterHarald Winroth 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformIntel i5OSWindowsOS Version7
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0013019: The ZIP package generator does not find the files when CPACK_PACKAGING_INSTALL_PREFIX is set
DescriptionI use components and generate one binary package ZIP for each component. If CPACK_PACKAGING_INSTALL_PREFIX is not set, everything works as expected. But when I set CPACK_PACKAGING_INSTALL_PREFIX to "/MyPrefix", the package generator is unable to find the files when compressing, resulting in the error message:

CPack: Create package
1>CPack Error: ERROR while packaging files: archive_read_disk_entry_from_file: (Empty error message)
1>CPack Error: Problem compressing the directory
Steps To ReproduceIn CMakeLists.txt:
set (CPACK_COMPONENTS_ALL core)
set (CPACK_ARCHIVE_COMPONENT_INSTALL 1)

In CPackProjectConfig.cmake:
set (CPACK_PACKAGING_INSTALL_PREFIX "/MyPrefix")

"C:\Program Files\CMake 2.8\bin\cpack.exe" -C Debug --config ./CPackConfig.cmake
Additional InformationIn Source\CPack\cmCPackGenerator.cxx line 849:

           localFileName =
                cmSystemTools::RelativePath(InstallPrefix, fit->c_str());
            localFileName =
                localFileName.substr(localFileName.find('/')+1,
                                     std::string::npos);

Now, when CPACK_PACKAGING_INSTALL_PREFIX is NOT set, fit is "C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core//bin/MyLib.dll" and InstallPrefix is "C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core/”.
Note the double slash in fit, it looks strange. After line 849 has executed, localFileName is "/bin/MyLib.dll”. Then, line 851 removes the leading slash, leaving "bin/MyLib.dll” in localFileName, and everything works.

However, if I set CPACK_PACKAGING_INSTALL_PREFIX to "/MyPrefix", then at line 849 above fit is "C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core/MyPrefix/bin/MyLib.dll" (note: no double slash in the path) and InstallPrefix is "C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core/MyPrefix". Line 489 sets localFileName to “bin/MyLib.dll” (which is the correct file name), but then line 851 strips of “bin/”, leaving just “MyLib.dll” in localFileName. That path will not be found later on.

But there also seems to be other problems in the code. The CPACK_PACKAGING_INSTALL_PREFIX doesn't seem to be taken into account futher down when the ZIP archive is created. Is the prefix parameter of the AddFile call suppose to be used for this?
TagsNo tags attached.
Relationships
related to 0013004closed Eric NOULARD Archive generator (TGZ, ZIP etc) doesn't work if component-based packaging is used with CPACK_SET_DESTDIR set to ON 
related to 0012606closed Eric NOULARD Archive and STGZ packages don't respect CPACK_PACKAGE_INSTALL_DIRECTORY (patch included) 
related to 0013157closed Eric NOULARD Tarball generator should obey CPACK_PACKAGE_INSTALL_DIRECTORY as the root directory in the tarball 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-03-06 10:00Harald WinrothNew Issue
2012-03-06 10:12Eric NOULARDNote Added: 0028842
2012-03-06 15:28Harald WinrothNote Added: 0028848
2012-03-06 15:35Eric NOULARDNote Added: 0028849
2012-03-06 16:03Harald WinrothNote Added: 0028850
2012-03-06 16:43Eric NOULARDNote Added: 0028851
2012-03-06 16:44Eric NOULARDRelationship addedrelated to 0013004
2012-03-06 16:45Eric NOULARDRelationship addedrelated to 0012606
2012-04-20 14:46Eric NOULARDRelationship addedrelated to 0013157
2012-08-11 21:35David ColeStatusnew => backlog
2012-08-11 21:35David ColeNote Added: 0030406
2016-06-10 14:28Kitware RobotNote Added: 0041997
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0028842)
Eric NOULARD   
2012-03-06 10:12   
Archive generators does not use (or handle) properly
CPACK_PACKAGING_INSTALL_PREFIX
and in fact may be they can't because the prefix is meant to be some
absolute path (as used by DEB or RPM generators)

They should use CPACK_PACKAGE_INSTALL_DIRECTORY
(as does NSIS generator) but again, they don't.

Note that this is not "component-related" this does not work with MONOLITHIC
package either!!

There are some related bugs to this I'll try to add links
and better explanation later.
(0028848)
Harald Winroth   
2012-03-06 15:28   
Are you sure about that? This problem was not present in CMake 2.8.4. In that version, setting CPACK_PACKAGING_INSTALL_PREFIX added the prefix to each of the files in the resulting zip archive, as expected.

Even in CMake 2.8.7, CPack will add CPACK_PACKAGING_INSTALL_PREFIX to the paths of the files collected under _CPack_Packages. The problem is that it uses the wrong file names when it later tries to create the zip archive.

I looked at the diff between 2.8.4 and 2.8.7, and there are changes all over the place. However, I suspect that the changes to cmCPackGenerator::InstallProjectViaInstallCMakeProjects play a role. That single function is almost 400 lines (!) and has grown almost 100 lines between 2.8.4 and 2.8.7.
(0028849)
Eric NOULARD   
2012-03-06 15:35   
Since you obviously tracked down a regression,
I'm not sure :-]

The growth of code in InstallProjectViaInstallCMakeProjects, comes
from addition of Component Support and many bug fixes.

This is no excuse but we obviously miss a systematic test for the
CPACK_PACKAGING_INSTALL_PREFIX usage.
I'll try to look into that, but If you are willing to try a patch
I'll happily review it.

What I'm [almost] sure is that:

set (CPACK_PACKAGING_INSTALL_PREFIX "/MyPrefix")

may not be what you want in archive generator?
Are you really wanting to create a ZIP or TGZ
with an absolute path in it?
(0028850)
Harald Winroth   
2012-03-06 16:03   
No, I don't want an absolute path in my zip. What I want is to insert a prefix so that the zip unpacks as ./MyPrefix/bin, ./MyPrefix/lib etc, instead of just ./bin and ./lib.

Setting CPACK_PACKAGING_INSTALL_PREFIX to "/MyPrefix" (with a leading slash) does just that in 2.8.4. The prefix is appended to _CPack_Packages/win32/ZIP/MyPackage-win32, so it need to include that leading slash.
(0028851)
Eric NOULARD   
2012-03-06 16:43   
Ok then this way of using it with archive generator is awkward
at best because you should usually use CPACK_PACKAGE_INSTALL_DIRECTORY
for this purpose and not CPACK_PACKAGING_INSTALL_PREFIX.

Moreover requiring the leading slash is really odd...

That said may be for Archive generator
CPACK_PACKAGING_INSTALL_PREFIX
should be used the same way as
CPACK_PACKAGE_INSTALL_DIRECTORY

Could you create a small standalone test case for that, I'll try
to integrate it in the test suite...
and may be dissect a little further
in order to find when exactly the behavior changed?

May be you already did that?
You said 2.8.4 was OK and 2.8.7 is not.
How are 2.8.5 and 2.8.6? (and may be 2.8.3)?

The way archive generator are handled changed drastically in 2.8.2
when the switch to libarchive was done.
(0030406)
David Cole   
2012-08-11 21:35   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

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 who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0041997)
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.