On Tue, Jul 19, 2005 at 11:09:56PM +0200, Richard Atterer wrote:
> I disagree; I think this is a nice feature. In my own program's configure
> script, I use this to distinguish between "yes", "no" and "auto"
> (auto-detect). All three are useful:
>
> The default setting "auto" is good for most people who run the configure
> script and who don't care much ATM whether they have, say, SSL support or
> not, they just want a compiled program quickly.
>
> An explicit "yes" is good for people who want the configure script to
> finish even though detection of the lib (or whatever) has failed. This may
> be because they prefer tweaking the Makefile over hacking the configure.ac,
> or because the configure script is buggy etc... I believe many people are
> uncomfortable with autoconf and its messy shell scripting.
>
> Unfortunately, there's no "style guide" for configure files which says that
> the user should always be able to make the script create Makefiles, even if
> the configure script has detected that compilation will fail.
>
> Another application for explicit "yes"/"no" options are autobuilders, e.g.
> daily snapshots or Debian's build daemons. You prefer that the build fails
> over the situation where the build suddenly lacks a feature and it takes a
> long time for people to find the cause and alert you.

That's a good point. And doing this way does certainly increase autoconf's
flexibilty, which in the absence of a "style guide" is a mixed blessing.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved