[cmake-developers] Welcome to June, time for the next release candidate

[Brad King]

On Tue, Jun 5, 2012 at 8:17 AM, Eric Noulard <eric.noulard at gmail.com> wrote:
> 2012/6/5 Kornel Benko <kornel at lyx.org>:
> Somebody shall dive into the build process of the libarchive Ubuntu package and
> see **why** it breaks the CMake build while using cmlibarchive does not.

This is the proper action.  What version of libarchive is used from the system?

The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn
rev 4051, now Git commit 28267d8f:

 https://github.com/libarchive/libarchive/tree/28267d8f/

plus some portability fixes.

> This "may-be" a usage error on CMake side (and I'll try to help to fix it)
> but this may well be a mistake on libarchive/Ubuntu side as well.
[snip]
> Yes but this action was widening the compatibility.
> pax_restricted --> gnutar may be narrowing it.

This was discussed here:

 http://www.cmake.org/Bug/view.php?id=11958

but many archive portability concerns were lifted by updating to a
libarchive that included this:

 https://github.com/libarchive/libarchive/commit/de60ddd0

The issue was resolved without changing formats by a fix suggested by
a libarchive maintainer:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8558efa

If there are extended headers that dpkg doesn't support then we need
to know why they appear in the first place and which ones can be
cleared.

-Brad