MantisBT - CMake
View Issue Details
0013072CMakeCPackpublic2012-03-29 10:332015-01-05 08:39
Mario Lang 
 
normalfeatureN/A
closedfixed 
CMake 2.8.7 
CMake 3.1CMake 3.1 
0013072: Allow CPack to generate tar.xz archives
For my project I'd like to use CPack to generate tar.xz source archives.
After a bit of poking around in the git repository I realized that xz support is already there in
the underlying library for handling archives. However, there is no Generator for TXZ.
The attached patch adds the necessary generator. Tested and works as expected for me.
I can set(CPACK_SOURCE_GENERATOR "TGZ;TXZ;") now and the result is just as expected.
A second patch (also to be attached) adds the CPACK_BINARY_TXZ and CPACK_SOURCE_TXZ options as well.
No tags attached.
duplicate of 0011040closed David Cole TXZ support to cpack 
related to 0013515closed  ExternalProject doesn’t handle .tar.xz 
related to 0014519closed  7z ( LZMA and LZMA2) support for cpack 
patch 0001-cmCPackTXZGenerator-Add-tar.xz-archive-generation.patch (5,155) 2012-03-29 10:33
https://public.kitware.com/Bug/file/4272/0001-cmCPackTXZGenerator-Add-tar.xz-archive-generation.patch
patch 0002-Add-CPACK_BINARY_TXZ-and-CPACK_SOURCE_TXZ-options.patch (2,499) 2012-03-29 10:36
https://public.kitware.com/Bug/file/4273/0002-Add-CPACK_BINARY_TXZ-and-CPACK_SOURCE_TXZ-options.patch
Issue History
2012-03-29 10:33Mario LangNew Issue
2012-03-29 10:33Mario LangFile Added: 0001-cmCPackTXZGenerator-Add-tar.xz-archive-generation.patch
2012-03-29 10:36Mario LangFile Added: 0002-Add-CPACK_BINARY_TXZ-and-CPACK_SOURCE_TXZ-options.patch
2012-03-30 11:20Eric NOULARDAssigned To => Eric NOULARD
2012-03-30 11:20Eric NOULARDStatusnew => assigned
2012-03-30 11:40Eric NOULARDNote Added: 0029008
2012-03-30 11:43Eric NOULARDAssigned ToEric NOULARD =>
2012-03-30 11:48Eric NOULARDRelationship addedhas duplicate 0001104
2012-03-30 11:52Eric NOULARDNote Added: 0029010
2012-03-30 13:04Brad KingRelationship addedduplicate of 0011040
2012-03-30 13:05Brad KingRelationship deletedhas duplicate 0001104
2012-03-30 13:06Eric NOULARDStatusassigned => new
2012-04-01 03:59Mario LangNote Added: 0029026
2012-04-01 04:39Eric NOULARDNote Added: 0029027
2012-04-01 04:39Eric NOULARDNote Edited: 0029027bug_revision_view_page.php?bugnote_id=29027#r591
2012-04-20 14:55Eric NOULARDNote Added: 0029278
2012-04-20 14:55Eric NOULARDAssigned To => Eric NOULARD
2012-04-20 14:55Eric NOULARDStatusnew => feedback
2012-06-23 10:58Shlomi FishNote Added: 0029816
2012-06-25 05:21Eric NOULARDNote Added: 0029821
2012-06-25 05:22Eric NOULARDNote Added: 0029822
2012-06-25 05:22Eric NOULARDStatusfeedback => new
2012-06-25 12:52Eric NOULARDAssigned ToEric NOULARD =>
2012-06-25 12:52Eric NOULARDStatusnew => feedback
2012-06-25 14:47Brad KingNote Added: 0029832
2012-08-14 17:35Eric NOULARDNote Added: 0030662
2012-08-14 17:35Eric NOULARDStatusfeedback => backlog
2012-09-05 06:42Eric NOULARDRelationship addedrelated to 0013515
2013-11-01 16:57Brad KingRelationship addedrelated to 0014519
2014-07-30 09:35Brad KingNote Added: 0036498
2014-07-30 09:35Brad KingStatusbacklog => resolved
2014-07-30 09:35Brad KingResolutionopen => fixed
2014-07-30 09:35Brad KingFixed in Version => CMake 3.1
2014-07-30 09:35Brad KingTarget Version => CMake 3.1
2015-01-05 08:39Robert MaynardNote Added: 0037595
2015-01-05 08:39Robert MaynardStatusresolved => closed

Notes
(0029008)
Eric NOULARD   
2012-03-30 11:40   
This looks fine but unfortnately this is may not be enough.

CMake should build on any host, LZMA lib being installed or not.
In order to achieve this for Bzip2, zip, z and gz compression
CMake includes:

Utilities/cmbzip2
Utilities/zlib

in its source tree.
Then options:

CMAKE_USE_SYSTEM_BZIP2 and CMAKE_USE_SYSTEM_ZLIB are used to toggle between
system version and shipped-in version of those libs.

What would happen if CMake is compiled on a host where lzma lib is not installed?

Will it fail to compile or will CPack have a non-functional TXZ generator?
(0029010)
Eric NOULARD   
2012-03-30 11:52   
Just remembered that there was a sibling bug closed some time ago,
I did add the relationship, but read David's comment about portability:

http://public.kitware.com/Bug/view.php?id=11040#c24155 [^]
(0029026)
Mario Lang   
2012-04-01 03:59   
> What would happen if CMake is compiled on a host where lzma lib is not installed?
> Will it fail to compile or will CPack have a non-functional TXZ generator?

Right now, Aas far as I can see, CPack will have a TXZ generator that reports that it was built without lzma support.
cmlibarchive has ifdefs for HAVE_LZMA and will provide stub functions with a warning.
From my POV, thats fine since TXZ is not enabled by default.
If a user chooses to enable TXZ they will either have success or get an appropriate error from CPack.
(0029027)
Eric NOULARD   
2012-04-01 04:39   
Hi Mario,

I let Kitware guys give their opinion on this, but CMake tries to avoid platform specific feature in his feature set unless it's obviously makes sense, like
not support Visual Studio Generator on Linux is just fine.

In the present case, the point of using libarchive is precisely the fact that
the same range of features are available on all CMake-supported platforms.

How would I write a portable CMakeLists.txt and use TXZ if I have not
"by-design" clue that TXZ will be available on a particular platform?

I can see two options for achieving this:

 1) Create something like cmxzutils (from http://tukaani.org/xz/ [^]) and
    ensure it compiles on all CMake supported platform
    Then your patch is ok.

 2) Create a TAR CPack generator (which does not exist yet)
    and authorize this generator to have a CPACK_TAR_POSTPROCESS
    option which could be used to specify a post-processing
    command on the file(s) produced by the TAR generator.

    set(CPACK_TAR_POSTPROCESS "xz;.xz;.txz")

    would mean than xz would be called on the file(s)
    resulting files would be appended the ".xz" suffix
    in the end it should be renamed .txz.

    This way one could write in its CMakeLists.txt
    find_program(XZ_PROGRAM NAMES xz)
    if (XZ_PROGRAM)
       list(APPEND CPACK_GENERATORS "TAR")
       set(CPACK_TAR_POSTPROCESS "${XZ_PROGRAM};.xz;.txz")
    else (XZ_PROGRAM)
       list(APPEND CPACK_GENERATORS "TBZ2")
    endif(XZ_PROGRAM)

(0029278)
Eric NOULARD   
2012-04-20 14:55   
Not working on this until I get feedback from other CMake dev.
Mario you can raise the discussion on cmake developer ML refering
to this if you want to try accelerate this process.
(0029816)
Shlomi Fish   
2012-06-23 10:58   
Since I'd also like to have tar.xz functionality in the upstream CMake, I've now requested feedback from the CMake developer mailing list:

http://public.kitware.com/pipermail/cmake-developers/2012-June/004431.html [^]

Regards,

— Shlomi Fish
(0029821)
Eric NOULARD   
2012-06-25 05:21   
I think that for portability reason it's not reasonable
to include LZMA unless we can include a portable lzma library
in the CMake source.
I won't have time to do that myself though.

Another solution would be to dynamically check (when running CPack)
that the TXZ generator may run.
This is now possible using
cmCPackXXXGenerator::CanGenerate() interface which was introduced
for dynamically enabling RPM and DEB generator on OS (cf 0013064).

The idea behind this is that the CPack generator
may always be compiled with the concerned generator activated
but the factory has a (simple) way to check whether if the generator
is usable or not **at run time**.
If the check is successfull then the generator may be used
(and appear in the cpack --help list) if not the factory
does not build the concerned generator and it does not appear
in the list.

The entry point for that behavior is the
cmCPackGeneratorFactory::cmCPackGeneratorFactory() constructor.
The CPack main program is using an instance of this factory class.
(0029822)
Eric NOULARD   
2012-06-25 05:22   
Unassigning until we have feedback
(0029832)
Brad King   
2012-06-25 14:47   
Approach 1 from 0013072:0029027 is the best IMO. We already have cmzlib and cmbzip2 along with cmlibarchive. Adding one for xz will be the most consistent approach. Of course every time we add a third-party library we always add a "use system" option for it. Furthermore we always end up making changes for portability or to disable features we do not need. The cleanest way to support such changes is to bring in the upstream version as a "reduced snapshot branch" as described in "Utilities/cmlibarchive/README-CMake.txt".
(0030662)
Eric NOULARD   
2012-08-14 17:35   
I won't have time to work on this for 2.8.10.
(0036498)
Brad King   
2014-07-30 09:35   
After a contributor ported liblzma to C89/90 for us we are finally able to implement lzma support in CPack:

 CPack: add generators for .7z and .tar.xz
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f931a18c [^]
(0037595)
Robert Maynard   
2015-01-05 08:39   
Closing resolved issues that have not been updated in more than 4 months