On Tue, Jul 19, 2005 at 12:36:56PM -0700, Dan Fandrich wrote:
> On Tue, Jul 19, 2005 at 03:31:21PM -0000, man_at_tfhs.net wrote:
> > IIRC, it is possible for "" to be considered 'yes' if the program wishes.
> > in this case --without and "" are not the same thing. or have i
> > overestimated the capabilites of autoconf?
>
> Yes, but my point is that the autoconf designers could have simplified
> the developer's job by allowing him to specify the default and treating
> it in exactly the same way as if the option were given on the command
> line. It's really just a complaint about style.

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.

Just my 2¢ (European),

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯