[cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Sat Jul 27 14:52:33 EDT 2013
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
__________________________
More information about the cmake-developers
mailing list