Re: gnome-libs and --disable-debug in the configure script

On 25 Jan 1999, Martin Baulig wrote:

> Gleef <> writes:
> > That's one of the more annoying quirks of autoconf.  Unless you go through
> > a lot of effort setting up the script, autoconf will
> > recognize both --enable-<feature> and --disable-<feature> as both doing
> > the same thing, toggling <feature> from the default behavior.  It leaves
> > it up to the configure script writer to set a default and list the correct
> > form of the option, and up to the person running configure to follow
> > directions :-).

I don't consider it "going through a lot of effort" when you are
following the docs.  It would be nice to be able to specify a default
value explicitly rather than implicitly with code.

> Yes, I agree - being forced to use
> -------
> AC_ARG_ENABLE(debug, [  --enable-debug turn on debugging [default=no]], enable_debug="$enableval", enable_debug=no)
> if test x$enable_debug = xyes ; then
> fi
> -------
> instead of something like
> -------
> AC_ARG_ENABLE(debug, [  --enable-debug turn on debugging [default=no]], AC_DEFINE(GNOME_ENABLE_DEBUG), AC_DEFINE(GNOME_DISABLE_DEBUG))
> -------
> is really annoying. I can understand this for the AC_ARG_WITH macro, here it
> makes sense to check the $withval, but AC_ARG_ENABLE ist just for enabling or
> disabling a feature.

AC_ARG_ENABLE can still take an argument.  For example, GLib's
--disable-threads, --enable-threads, --enable-threads=posix,
--enable-threads=nspr, etc.

The autoconf macro code for AC_ARG_WITH and AC_ARG_ENABLE is _exactly_
the same, save for the variable names.  Thus the difference is mainly
preference and semantics.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]