Re: lzip support

2008-11-29 Thread Jim Meyering
Jan Engelhardt [EMAIL PROTECTED] wrote: On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake already had LZMA support, can someone please explain LZIP vs LZMA and why we now have at least

Re: lzip support

2008-11-29 Thread Jan Engelhardt
On Saturday 2008-11-29 10:06, Jim Meyering wrote: Jan Engelhardt [EMAIL PROTECTED] wrote: On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake already had LZMA support, can someone please

Re: simple distcheck fails

2008-11-29 Thread Ralf Wildenhues
* Jan Engelhardt wrote on Fri, Nov 28, 2008 at 08:51:58PM CET: Sigh, I so really prefer doing a git-archive HEAD | tar -C /tmp/whereever -xf- run autogen.sh in whereever pack up the stuff over distcheck atm :-P The above is an approximation of 'make dist', not of distcheck. I think

Re: lzip support

2008-11-29 Thread Jim Meyering
Jan Engelhardt [EMAIL PROTECTED] wrote: On Saturday 2008-11-29 10:06, Jim Meyering wrote: Jan Engelhardt [EMAIL PROTECTED] wrote: On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake

Re: lzip support

2008-11-29 Thread Bob Friesenhahn
On Sat, 29 Nov 2008, Jim Meyering wrote: I have been following lzma-utils development closely for some time, and my impression is that xz obviates lzip. I would not want to encourage use of lzip without a convincing argument to the contrary. As soon as there's a beta xz release (i.e., stable

Re: lzip support

2008-11-29 Thread Jan Engelhardt
On Saturday 2008-11-29 17:04, Bob Friesenhahn wrote: On Sat, 29 Nov 2008, Jim Meyering wrote: I have been following lzma-utils development closely for some time, and my impression is that xz obviates lzip. I would not want to encourage use of lzip without a convincing argument to the

Re: lzip support

2008-11-29 Thread Jim Meyering
Bob Friesenhahn [EMAIL PROTECTED] wrote: On Sat, 29 Nov 2008, Jim Meyering wrote: I have been following lzma-utils development closely for some time, and my impression is that xz obviates lzip. I would not want to encourage use of lzip without a convincing argument to the contrary. As soon

Re: lzip support

2008-11-29 Thread Ralf Wildenhues
On Friday 2008-11-28 21:37, Bob Friesenhahn wrote: It makes sense to me that periodically Automake maintainers make an evaluation (and with the blessing of the FSF) intentionally deprecate generation of certain archive types as new archive types are added. The intention would be to

Re: lzip support

2008-11-29 Thread Ralf Wildenhues
Hello, * Jim Meyering wrote on Sat, Nov 29, 2008 at 05:13:04PM CET: Bob Friesenhahn [EMAIL PROTECTED] wrote: If new formats are added, the least worthy of the existing supported distribution formats should be deprecated and eventually removed. This means that if .xz is added that .lzma

Re: lzip support

2008-11-29 Thread Jan Engelhardt
On Saturday 2008-11-29 17:30, Ralf Wildenhues wrote: On Friday 2008-11-28 21:37, Bob Friesenhahn wrote: It makes sense to me that periodically Automake maintainers make an evaluation (and with the blessing of the FSF) intentionally deprecate generation of certain archive types as new

Re: lzip support

2008-11-29 Thread Bob Friesenhahn
On Sat, 29 Nov 2008, Ralf Wildenhues wrote: On Friday 2008-11-28 21:37, Bob Friesenhahn wrote: It makes sense to me that periodically Automake maintainers make an evaluation (and with the blessing of the FSF) intentionally deprecate generation of certain archive types as new archive types are

Re: building a qt library

2008-11-29 Thread Lorenzo Bettini
Craig Sanders wrote: Greetings Lorenzo. I have used the GNU Autotools in the past to build some simple projects which made use of the Qt Library. I prefer to use the GNU Autotools as I find them much more flexible and much more powerful than qmake. As I recall, there are 2 key steps that

Multilib sources and variables

2008-11-29 Thread NightStrike
Is the following kosher? shell32src=libsrc/shell32.c lib32_LIBRARIES += lib32/libshell32.a lib32_libshell32_a_SOURCES = $shell32src lib32_libshell32_a_CPPFLAGS = -m32 lib64_LIBRARIES += lib64/libshell32.a lib64_libshell32_a_SOURCES = $shell32src Basically, all the sources are the same, so I

Re: Multilib sources and variables

2008-11-29 Thread Jan Engelhardt
On Sunday 2008-11-30 01:52, NightStrike wrote: Is the following kosher? It will produce two 32-bit libraries on all architectures where gcc defaults to a 32-bit output. shell32src=libsrc/shell32.c lib32_LIBRARIES += lib32/libshell32.a lib32_libshell32_a_SOURCES = $shell32src

Re: Multilib sources and variables

2008-11-29 Thread Ralf Wildenhues
* NightStrike wrote on Sun, Nov 30, 2008 at 01:52:23AM CET: Is the following kosher? Yes, except that you need to use $(shell32src) instead of $shell32src in both places. shell32src=libsrc/shell32.c lib32_LIBRARIES += lib32/libshell32.a lib32_libshell32_a_SOURCES = $shell32src

Re: missing help2man

2008-11-29 Thread Ralf Wildenhues
* Karl Berry wrote on Sat, Nov 29, 2008 at 12:34:40AM CET: Check that none of the man pages contain the error message. If any do, error out with a descriptive message. Ok, sounds good. We could also move such a check into 'distcheck'. That way 'dist' could still work if

Re: missing help2man

2008-11-29 Thread Karl Berry
I'm still wondering about whether and how to document this in the manual. I think one place would be the Preparing Distributions node, explaining that distcheck and dist will fail if `missing'-generated man pages are present. And perhaps the maintainer-mode node, since that is where

Fixup release rules.

2008-11-29 Thread Ralf Wildenhues
I'm pushing this patch to fix up the release rules, master and branch-1-10. Cheers, Ralf Fixup release rules. * Makefile.am (cvs-diff): Remove. (git-dist): Do not use clcommit any more. Use new-style tag name. Pass $(AM_MAKEFLAGS) to $(MAKE). (git-diff): Adjust.