On Friday 04 February 2005 21:17, Paul Eggert wrote: > Stepan Kasal <kasal@xxxxxx> 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). _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
