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

[Alan W. Irwin]

On 2013-07-26 17:02-0700 Alan W. Irwin wrote:

> On 2013-07-26 17:03-0400 Brad King wrote:
>
>> I'll finish the full update and integration into CMake when I
>> get a chance.
>
> When you do that please make sure the small file-pattern patch to
> ExternalProject.cmake given at
> http://public.kitware.com/Bug/view.php?id=14318 gets into CMake so
> that that your fix to allow unpacking of *.tar.xz tarballs on MSYS can
> be used via ExternalProject_Add.  The file-pattern patch also allows
> unpacking of *.tar.xz tarballs on Unix via ExternalProject_Add.

Hi Brad:

One other point which may be of interest here to those trying to use
current releases of CMake is I have implemented a change in the
ExternalProject module that works around the out-of-date libarchive
import issue referred to above. That workaround replaces the cmake -E
tar call as follows:

Index: ExternalProject.cmake
===================================================================
--- ExternalProject.cmake	(revision 12436)
+++ ExternalProject.cmake	(working copy)
@@ -543,9 +543,18 @@
  # Extract it:
  #
  message(STATUS \"extracting... [tar ${args}]\")
-execute_process(COMMAND \${CMAKE_COMMAND} -E tar ${args} \${filename}
-  WORKING_DIRECTORY \${ut_dir}
-  RESULT_VARIABLE rv)
+if(filename MATCHES \"tar\\\\.xz$\")
+  # --force-local required so that drive-letter colon for filename on
+  # Windows platforms is not interpreted as a remote host.
+  find_program(TAR_EXECUTABLE tar)
+  execute_process(COMMAND \${TAR_EXECUTABLE} --force-local -Jxf \${filename}
+    WORKING_DIRECTORY \${ut_dir}
+    RESULT_VARIABLE rv)
+else(filename MATCHES \"tar\\\\.xz$\")
+  execute_process(COMMAND \${CMAKE_COMMAND} -E tar ${args} \${filename}
+    WORKING_DIRECTORY \${ut_dir}
+    RESULT_VARIABLE rv)
+endif(filename MATCHES \"tar\\\\.xz$\")

  if(NOT rv EQUAL 0)
    message(STATUS \"extracting... [error clean up]\")

My initial implementation of the workaround was fine on Linux but
failed on MSYS. After a lot of thrashing around, I discovered just now
that a colon in the tarball name is significant for the tar command.
That signals the tarball must be obtained from a remote host using
rsh, and, of course, the Windows platform drive letters terminated
with a colon are completely antithetical to that interpretation.
Therefore, the solution is to use the above --force-local option which
makes tar ignore any special interpretation of colon in the filename.

The above workaround should be used in conjunction with the above
file-pattern patch until that patch and also your local import of a
recent libarchive become part of a new CMake release.

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
__________________________