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: Gregorio Guidi
Subject: Re: optional features and AC_ARG_WITH
Date: Sat, 5 Feb 2005 01:01:03 +0100
User-agent: KMail/1.7.1

On Friday 04 February 2005 21:17, Paul Eggert wrote:
> Stepan Kasal <address@hidden> writes:
> > 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''.
>
> I am starting to see the problem here.  The Autoconf manual says that
> the interpretation of --with-foo is up to the developers.  The Samba
> developers apparently came up with an interpretation that is
> inconvenient for some distributors.
>
> However, I still don't see the full problem here.  Why can't you
> simply avoid --with-acl entirely, when running ./configure?  Won't
> that give you ACL support if possible, and avoid it if not?

The real problem for distributors is when the --with* option is not provided 
by the developer. In fact, the samba case is quite a lucky one, and I think 
the interpretation of --with-acl-support from samba is the correct one, by 
the way...

Here's the main problem: software x checks if acl is available on the system 
during the ./configure run. If it finds it, it links against it, otherwise it 
will disable acl support. No AC_ARG_WITH(acl, ...) is provided.
I want to create a package for x that has acl support disabled, because it's 
not safe, or not needed, ... I build the package on a box that doesn't have 
acl, and ship it. Then, the user rebuilds the package on a box with acl 
installed. As a result, the package will be linked to acl, which is a problem 
because the package does not reflect this fact in its dependency listing, 
because it will totally break if acl is uninstalled..., ans so on.
To avoid this, it should be possible to build software x in a way that does 
not depend on the building host, and this is only possible if x supports 
AC_ARG_WITH() or AC_ARG_ENABLE() for every optional feature it has
(so that I can add --without-acl to the package building instructions...).

And here comes the child problem: since the interpretation of AC_ARG_WITH is 
up to the developer, even if I suggest to the developer to add AC_ARG_WITH to 
his configure.ac, I cannot expect that he implements it in a standard way.
And as shown by the samba example, there are millions of different 
interpretations of AC_ARG_WITH out there.

I think the 'standard' way to use AC_ARG_WITH (from the packager's point of 
view) in a case such as the acl one, should be like this:
If the user gave --without-acl, disable acl support without checking if it's 
available on the system.
If the user gave --with-acl, check if acl is available on the system and 
enable it; if acl cannot be found on the system, fail with an error (because 
the user explicitely requested acl support).
If the user didn't give --with-acl or --without-acl, check for acl and enable 
it if it's availabe.
This will ensure that if I explicitely add --with-acl or --without-acl to the 
building instructions, the package will be exactly as I wanted it to be.

Unfortunately, this is tricky to explain to the developer.
So I think we should:

for main problem: encourage the use of AC_ARG_WITH and AC_ARG_ENABLE.

for child problem: provide a standard interpretation of those macros (either 
through a macro that standardizes the use of AC_ARG_WITH/AC_ARG_ENABLE, such 
as the ones I posted at the beginning; or through some more precise 
documentation on their use, so that I can point to it when interacting with 
software developers).




reply via email to

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