[cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS

Alan W. Irwin irwin at beluga.phys.uvic.ca
Wed Jul 24 14:07:47 EDT 2013


On 2013-07-24 16:09-0000 David Cole wrote:

>> In sum this "cmake -E tar" issue for *.tar.xz files needs confirmation
>> for MSYS on the Microsoft version of Windows.  I am pretty sure this
>> is a simple issue since under MSYS handling of *.tar.xz files is
>> straightforward from the command line, and my understanding is that
>> libarchive drops back to the command line when necessary.  However, to
>> help me generate the appropriate cmake patch I need some further
>> guidance to where in Utilities/cmlibarchive/libarchive I should be
>> looking.
>
>
> libarchive is a “3rd party library” imported into CMake periodically when important updates are made in the upstream library. The difference between the upstream snapshot and what’s in CMake should be minimal.
>
>
> Perhaps you should inquire about this problem on the libarchive mailing list, and see if you can get any guidance there. The fix should be made in upstream libarchive, and then pulled into CMake next time the snapshot is updated.
>
>
> Of course, if you have a trivial one-line fix or something close to it, patching both simultaneously is reasonable. But it should definitely be fixed in upstream libarchive as well if that’s where the problem code is...
>
>
> Sorry I’m not an expert on the libarchive code, and can’t give you a pointer where to look... but I bet somebody on the libarchive list would have a better shot at giving you that pointer.
>
>
> libarchive project page: http://code.google.com/p/libarchive/
>

Upstream libarchive is certainly another avenue to explore.  For that
case probably the best thing to do would be to try and build
libarchive on MinGW/MSYS/Wine and test it for *.tar.xz files, and if
any part of that does not work, refer the question to the libarchive
list.

Of course, such an approach may simply demonstrate that recent
upstream libarchive is fine (see further comments below).  But I will
try this approach if I cannot find some other simple fix in CMake for
the issue.

Meanwhile, can someone with access to MSYS on the Microsoft
version of Windows try, for example, the simple experiment of 
downloading
http://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz and
unpacking that with

cmake -E tar xfz glib-2.32.1.tar.xz

to verify (or not) the issue?

With regard to the question of the libarchive version that has been
imported into CMake, from Utilities/cmlibarchive/README-CMake.txt it
appears the last commit that merged upstream libarchive was 4f4fe6e
(where details of that commit are given at
http://www.cmake.org/pipermail/cmake-commits/2012-January/011742.html).
Thus, cmake appears to be using a version of libarchive that is at
least one and a half years old.  A new import of libarchive may be
all that is required to solve this cmake -E tar issue for *.tar.xz
files on MSYS (assuming the issue is confirmed as above).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



More information about the cmake-developers mailing list