autoconf
[Top][All Lists]
Advanced

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

Re: optional features and AC_ARG_WITH


From: Stepan Kasal
Subject: Re: optional features and AC_ARG_WITH
Date: Fri, 4 Feb 2005 11:29:54 +0100
User-agent: Mutt/1.4.1i

Hi,
  I'd also like to se a clear resolution about Georgio's question.
I think I understand what he is asking for, thus I hope I won't do
any harm if I rephrase the question.

On Thu, Feb 03, 2005 at 11:43:54PM -0800, Paul Eggert wrote:
> Dan Manthey <address@hidden> writes:
> > On Thu, 3 Feb 2005, Braden McDaniel wrote:
> >> Paul Eggert wrote:
> >> I think Paul meant "--enable*".
> > Actually, I think --with* is the relevant case here,

I'd say he meant "user-visible features" and both --with* and --enable*
can be relevant here.

One example can be --with-pcre (Perl Compatible RE lib), another can be
--enable-solver, where the solver feature can be compiled only if glpk
(a linear programming kit) is available.

In both cases, the question is what to do, if user asks for this, but the
prerequisities are not ready.  Abort or silently continue as if the option
were not given?

> >   for p in $packages; do
> >     (cd $p;  ./configure $all-my-desired-with-options)
> >   done

One example:

I use a source distribution which does something like this:

with_options="--with-syslog ... --with-acl-support"
./configure ... $with_options

When I wanted to compile the distribution for a configuration without the
acl package, I had to modify it:

with_options="--with-syslog ... "
pkgcheck acl && with_options="$with_options --with-acl-support"
./configure ... $with_options

The samba developers interpreted --with-acl-support as a firm decision,
so the configure script aborts if the acl prerequisities are not available.

But the intention of the distribution builders was rather like ``I'd like
to have acl support, if possible''.

So the Question is:
Which interpretation is right?  How could we promote a consistent
interpretation?

Maybe Paul is right that it won't help to introduce yet-another-macro.
Perhaps we need a documentation clarification instead.
Georgio, could you look at the current CVS version of the autoconf manual,
to see how AC_ARG_{ENABLE,WITH} are defined and look how it could be
clarified?  Would you volunteer to write a patch to doc/autoconf.texi if
we reach a consensus?

My humble opinion about this question:

The behaviour of samba package, as described above, seems to be correct:
If the option is given, the configure script is not allowed to switch it
off because it _thinks_ there are missing prerequisities.  In most cases
the missing prerequisities will cause the subsequent "make" to fail, but
that's what the user asked for.  If the configure script gets really
confused, it can abort, but it shouldn't fall back to disable the option.

But I'm afraid that the script is not allowed to skip the autodetection
code, even though it is going to ignore the results.  The reason is that
if you write:

if test x$enable_this != xno; then
  AC_MACRO_ONE
fi
AC_MACRO_TWO

it is possible that there is a common prerequisite of both macros; it'd
get expanded just before AC_MACRO_ONE, so it could be skipped and
AC_MACRO_TWO cound fail.
So you have to be very careful with macro calls which are not always
reached.

Have a nice day,
        Stepan Kasal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]