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
__________________________
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
