Henrik K wrote: > On Sun, Mar 01, 2009 at 04:11:08PM -0500, Nathan Brink wrote: > >> I don't like it when other programs do this because it departs from the >> normal output of ./configure scripts. >> > > What exactly are you doing with the output that it bothers you and where is > this "standard" defined? > The standard is defined by the implementation of autoconf which many projects use. Most will just run and give the output of ./configure to the screen. It bothers me when people write wrappers for ./configure, like ./Config for unrealircd, or when ./configure is messed with much in other ways. People should be able to read ./configure --help and purposefully enable and disable the optional packages, etc. that they want. ./configure should die when these are unsatisfiable; the test that wasn't satisfied is printed right before it dies, making it easy to locate. Then the user will know what package he is missing/what's wrong with his system/what incompatibilities there are that would prevent that feature from being enabled. The user can then fix the problem by, for instance, installing the missing package or knowingly disabling it. This encourages users to be knowledgeable about what they are doing. Also, the fact that a user originally wrote --enable-milter and rewrote it to --disable-milter (for example) to get clamav to compile will help the user remember that he disabled milter support before asking ``Where'd the milter go?''.
I guess I'd be willing to say this: I personally don't see how summaries would help me even though they may help others. Especially when my package manager compiles ClamAV for me (as soon as I update my ebuilds...). -- binki _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
