On Tue, Dec 27, 2011 at 02:18, Bob Friesenhahn <[email protected]> wrote: > From a layman's standpoint, I noticed right away that lzip is small and in > the spirit of gzip and bzip2 whereas xz is huge (10X more source code last > time I checked) and has many more lines of configure script than lzip has of > source code in its entirety.
I've never used lzip or xz. Hell, so far I've only created a handful of .bz2 files myself (one-off convenience stuff). I do not take any position on inclusion of xz or lzip support in Automake's make dist. I do question the usefulness of comparing lines counts of Autoconf-generated configure script and source code. If you're trying to elicit support from maintainers of oft-maligned yet widely-used autotools, you've chosen an interesting way of warming up your audience. > However, lzip is written in portable C++ (rather than C) and does not > configure via autotools (because it uses only portable C++) so it is at a > political disadvantage. I'm not sure how using only portable C++ eliminates autotools utility. I can see that using C++ means never having to care about some esoteric ancient history relevant only to older and/or less mainstream systems and compilers, but it seems to me much the same can be said of requiring C99? I've never used SCons either, though I've been paying attention to one project that recently switched from Autotools and is generating a steady stream of "doesn't build on X brand widely-deployed system" months later. My impression is the simplifications SCons brought have come at a substantial portability price, though I'm sure with enough effort and time the squeakiest platforms with issues will get some grease, I suspect the project in question will not ever be as portable with SCons as it was with the hated Autotools. I appreciate that many Autoconf + Automake users can't be bothered to understand how Autotools works or what m4 is, and yet manage to copy/paste and blindly experiment enough to scrape along. I hope more of them switch to SCons and other Autotools alternatives, which may well be better for their project, but in any case would mean less whinging Autotools-dependent projects blaming tools which they can't be bothered to learn to use for their shortcomings. m4 is so inside-out of the way most programmers think, and Autotools for simpler cases hide that entirely behind a blissfully simplified facade of m4 macros invocation that many can use without understanding, until things get slightly less boilerplate. Then out come the pitchfork-wielding masses blaming their unknowable black boxes rather than take the time to hump the Autoconf and Automake learning curve. Grinchfully, Dave Hart
