Re: support for lzma in automake?
[EMAIL PROTECTED] (Karl Berry) wrote: Could we have a new option in automake for making lzma-compressed tarballs, a la bzip2? The package to use is lzma-utils, from http://tukaani.org/lzma/. Generally, it compresses better and uncompresses faster than bzip. Not just better. Significantly better. Coreutils compressed tarball goes from 5.3MB w/.bz2 to 3.3MB w/.lzma. Emacs goes from ~30MB to ~24MB. Decompression time is 2x to 2.5x faster. Not surprisingly, compression is slower: from ~2x for coreutils to about 3.5x for emacs.
Re: support for lzma in automake?
[EMAIL PROTECTED] (Karl Berry) wrote:
Could we have a new option in automake for making lzma-compressed
tarballs, a la bzip2? The package to use is lzma-utils, from
http://tukaani.org/lzma/. Generally, it compresses better and
uncompresses faster than bzip.
Jim, perhaps you would like to supply a patch :)? (Jim was the one who
instigated this.)
Here's the patch. It works for coreutils.
It also passed make check, well at least up to pr401.test
where I interrupted it.
[BTW, if there's interest (ha!) I will set up a read-only git mirror
on sourceware.org of the primary automake-cvs repository there.
Lvm2 and device-mapper were the first test subjects there:
http://sources.redhat.com/git/gitweb.cgi
]
2007-10-07 Jim Meyering [EMAIL PROTECTED]
Add lzma compression support.
* NEWS: Mention it.
* automake.in (handle_dist): Recognize dist-lzma.
(make_paragraphs): Map LZMA to dist-lzma.
* doc/automake.texi (Dist): Add dist-lzma.
(Options): Likewise.
* lib/Automake/Options.pm (_process_option_list):
* lib/am/distdir.am (dist-lzma): New rule.
(dist dist-all): Add command to create an lzma-compressed tarball.
(distcheck): Handle lzma-compressed tarballs just like the others.
* tests/defs.in: Test for lzma, too.
* tests/lzma.test: New file, based on nogzip.test.
* tests/Makefile.am (TESTS): Add lzma.test.
I'll commit it in a couple days.
Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
NEWS|2 ++
automake.in |3 ++-
doc/automake.texi | 15 +--
lib/Automake/Options.pm |3 ++-
lib/am/distdir.am |9 +
tests/Makefile.am |1 +
tests/defs.in |4
tests/lzma.test | 45 +
8 files changed, 78 insertions(+), 4 deletions(-)
create mode 100755 tests/lzma.test
diff --git a/NEWS b/NEWS
index 6304757..467208e 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,8 @@ New in 1.10a:
* Miscellaneous changes:
+ - Supports lzma-compressed tarballs.
+
- Automake is licensed under GPLv3+. `automake --add-missing' will
by default install the GPLv3 file as COPYING if it is missing.
Note that Automake will never overwrite an existing COPYING file,
diff --git a/automake.in b/automake.in
index 47023ba..234947b 100755
--- a/automake.in
+++ b/automake.in
@@ -3613,7 +3613,7 @@ sub handle_dist ()
{
my $archive_defined = option 'no-dist-gzip' ? 0 : 1;
$archive_defined ||=
- grep { option dist-$_ } ('shar', 'zip', 'tarZ', 'bzip2');
+ grep { option dist-$_ } qw(shar zip tarZ bzip2 lzma);
error (option 'no-dist-gzip',
no-dist-gzip specified but no dist-* specified,
. at least one archive format must be enabled)
@@ -6446,6 +6446,7 @@ sub make_paragraphs ($%)
'MAINTAINER-MODE'
= $seen_maint_mode ? subst ('MAINTAINER_MODE_TRUE') : '',
+'LZMA'= !! option 'dist-lzma',
'BZIP2' = !! option 'dist-bzip2',
'COMPRESS'= !! option 'dist-tarZ',
'GZIP'= ! option 'no-dist-gzip',
diff --git a/doc/automake.texi b/doc/automake.texi
index b3361d3..1b7e521 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -8082,6 +8082,11 @@ frequently smaller than gzipped archives.
Generate a gzip tar archive of the distribution.
@trindex dist-gzip
[EMAIL PROTECTED] @code{dist-lzma}
+Generate a lzma tar archive of the distribution. lzma archives are
+frequently smaller than bzipped archives.
[EMAIL PROTECTED] dist-lzma
+
@item @code{dist-shar}
Generate a shar archive of the distribution.
@trindex dist-shar
@@ -8369,6 +8374,12 @@ Cause @command{dejagnu}-specific rules to be generated.
@xref{Tests}.
Hook @code{dist-bzip2} to @code{dist}.
@trindex dist-bzip2
[EMAIL PROTECTED] @option{dist-lzma}
[EMAIL PROTECTED] Option, @option{dist-lzma}
[EMAIL PROTECTED] dist-lzma
+Hook @code{dist-lzma} to @code{dist}.
[EMAIL PROTECTED] dist-lzma
+
@item @option{dist-shar}
@cindex Option, @option{dist-shar}
@opindex dist-shar
@@ -8540,7 +8551,7 @@ In order to use this option with C sources, you should add
These three mutually exclusive options select the tar format to use
when generating tarballs with @samp{make dist}. (The tar file created
is then compressed according to the set of @option{no-dist-gzip},
[EMAIL PROTECTED] and @option{dist-tarZ} options in use.)
[EMAIL PROTECTED], @option{dist-lzma} and @option{dist-tarZ} options in use.)
These options must be passed as argument to @code{AM_INIT_AUTOMAKE}
(@pxref{Macros}) because they can require additional configure checks.
@@ -12074,4 +12085,4 @@ The number of test cases in the test suite.
@c LocalWords: LTALLOCA MALLOC malloc memcmp strdup alloca libcompat xyz DFOO
@c LocalWords: unprefixed buildable preprocessed DBAZ DDATADIR
Re: support for lzma in automake?
On Oct 7, 2007, at 11:44 AM, Jim Meyering wrote: BTW, if there's interest (ha!) I will set up a read-only git mirror on sourceware.org of the primary automake-cvs repository there. Lvm2 and device-mapper were the first test subjects there: http://sources.redhat.com/git/gitweb.cgi I'd be interested indeed. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part
Re: files left in build directory after distclean using subdir-objects
On Oct 7, 2007, at 7:36 AM, Braden McDaniel wrote: On Sat, 2007-10-06 at 14:18 -0400, Braden McDaniel wrote: [snip] Might I be tripping over some bug that occurs when the subdirectory name is the same as the built executable? The addition of CLEANFILES = openvrml-xembed/.libs/openvrml-xembed has worked around the problem. Suboptimal, I know, since .libs is an implementation detail of libtool. Hello Braden, I downloaded OpenVRML 0.16.6 from sourceforge but couldn't get past configure (I'm on OSX and have Boost installed under /opt/local and although your configure script doesn't provide any way to indicate where Boost is, I passed it CPPFLAGS='-I/opt/local/include' and LDFLAGS='-L/opt/local/lib', but it was looking for -lboost_thread, except that it is common to not have libboost_thread.* while having libboost_thread-mt.* -- for instance). Anyways, would it be possible for you to shrink down the problem to a small configure script and Makefile.am so that others can try to reproduce it easily? Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part
Re: files left in build directory after distclean using subdir-objects
On Sun, 2007-10-07 at 18:59 +0200, Benoit SIGOURE wrote: On Oct 7, 2007, at 7:36 AM, Braden McDaniel wrote: On Sat, 2007-10-06 at 14:18 -0400, Braden McDaniel wrote: [snip] Might I be tripping over some bug that occurs when the subdirectory name is the same as the built executable? The addition of CLEANFILES = openvrml-xembed/.libs/openvrml-xembed has worked around the problem. Suboptimal, I know, since .libs is an implementation detail of libtool. Hello Braden, I downloaded OpenVRML 0.16.6 from sourceforge but couldn't get past configure (I'm on OSX and have Boost installed under /opt/local and although your configure script doesn't provide any way to indicate where Boost is, I passed it CPPFLAGS='-I/opt/local/include' and LDFLAGS='-L/opt/local/lib', but it was looking for -lboost_thread, except that it is common to not have libboost_thread.* while having libboost_thread-mt.* -- for instance). You won't see the problem in the 0.16.6 release, anyway. It is on the CVS HEAD, though. You will need to comment out the aforementioned CLEANFILES occurrence in src/Makefile.am in order to observe the problem. The solution to the problem you encountered is to set BOOST_LIB_SUFFIX=-mt at configure time. I have successfully configured OpenVRML using the MacPorts toolchain (which it sounds like you might also be using) with the following options: $ ../configure -C --prefix=$HOME --disable-static --enable-gtk-doc --with-apple-opengl-framework --with-libjs --disable-mozilla-plugin CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib BOOST_LIB_SUFFIX=-mt You will need to get gtk-doc, libgnomeui, libglade2, and spidermonkey from MacPorts if you don't already have them. Also libsdl; or pass --disable-examples. The spidermonkey dependency can also be suppressed by passing --disable-script-node-javascript instead of --with-libjs. Anyways, would it be possible for you to shrink down the problem to a small configure script and Makefile.am so that others can try to reproduce it easily? I don't know. Given the fact that this problem has occurred for one program and not the other, it's not obvious to me what could be triggering this behavior. As I mentioned, the install location is the only difference that jumps out at me. -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED]
Re: files left in build directory after distclean using subdir-objects
On Sun, 2007-10-07 at 16:41 -0400, Braden McDaniel wrote: [snip] I have successfully configured OpenVRML using the MacPorts toolchain (which it sounds like you might also be using) with the following options: $ ../configure -C --prefix=$HOME --disable-static --enable-gtk-doc --with-apple-opengl-framework --with-libjs --disable-mozilla-plugin CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib BOOST_LIB_SUFFIX=-mt Unfortunately, after that, it seems it doesn't build because some of the gtkglext configure tests don't work correctly with MacPorts. I will work on fixing that. -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED]
Re: files left in build directory after distclean using subdir-objects
On Sun, 2007-10-07 at 18:06 -0400, Braden McDaniel wrote: On Sun, 2007-10-07 at 16:41 -0400, Braden McDaniel wrote: [snip] I have successfully configured OpenVRML using the MacPorts toolchain (which it sounds like you might also be using) with the following options: $ ../configure -C --prefix=$HOME --disable-static --enable-gtk-doc --with-apple-opengl-framework --with-libjs --disable-mozilla-plugin CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib BOOST_LIB_SUFFIX=-mt Unfortunately, after that, it seems it doesn't build because some of the gtkglext configure tests don't work correctly with MacPorts. I will work on fixing that. Fix checked in. However, for some reason AC_PATH_X(TRA) on MacPorts doesn't set x_includes/X_CFLAGS--even though it apparently needs to. As a result, you need to configure with --x-includes=/usr/X11R6/include. -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED]
