Hi,
being involved in the process of redristibuting software packages for the
Gentoo distribution, I'm often dealing with autoconf stuff, and I would like
to share a thuoght.
As you can imagine, a very common (if not the most common) use case for code
in configure.in/configure.ac is the following: run a check, see the result,
and decide if a specific feature of the software should be enabled or
disabled.
In an ideal world, this would be done in two steps:
- use AC_ARG_WITH or AC_ARG_ENABLE to provide a configure switch for the
feature.
- run the test, taking into account the will of the user as expressed in the
configure switch, and decide whether to enable or disable the feature.
Unfortunately, there's no standardized way to perform such action. Since
developers are usually lazy, they don't provide the --with or --enable switch
(and even when they provide it, there's no consistency: what to do if
--with-foo was given but the foo library is not installed? abort or disable
foo? What to do if --without-foo was given? Run the test for libfoo anyway or
not?).
This causes lots of problems for us (software packagers), for the following
reason:
it is very important when creating a package to know in advance what features
will be enabled in the software at the end of the process, without knowing
the details of the host where the package is building.
This is true in particular for source based distributions (Gentoo as well as
others), where the build process takes place on the user box; but also
applies to binary distributions (think doing 'rpmbuild --rebuild package'),
and the packager should not worry about his building host anyway.
So, it would be important to ease the addition of configure switches for all
available features, and to do it in a consistent way. Currently autoconf
lacks some tool to accomplish this goal.
So I'm asking: could it be a good idea as a long-term solution to advertise
among software developers the adoption of some standardized macro that could
make it easier to add configure switches, such as the macros that I'm
attaching below?
Please take a look at them and see if there are errors, and feel free to
comment on them. Does it makes sense to propose them to software developers?
dnl @synopsis AX_ARG_WITH_CHECK(PACKAGE, HELP-STRING, RESULT-ID, TEST-SCRIPT,
ACTION-IF-TRUE [, ACTION-IF-FALSE])
dnl
dnl @summary Check for an external requirement and add a switch to force it on
or off.
dnl
dnl This macro is used to peform a test on the availability
dnl of a feature that needs an external requirement, giving
dnl the user the possibility to explicitely enable or
dnl disable the feature through a configure switch.
dnl
dnl If the user gave `configure' the option `--with-PACKAGE',
dnl or no option was given, run commands TEST-SCRIPT, which
dnl are supposed to store the result in RESULT-ID. If the value
dnl of RESULT-ID is `no', the test is considered failed, and
dnl ACTION-IF-FALSE is run. Any other value is considered a
dnl success, and ACTION-IF-TRUE is run. If the user gave
dnl `--without-PACKAGE', ACTION-IF-FALSE is run. If the user
dnl gave `--with-PACKAGE' and the test failed, exit with an
dnl error.
dnl
dnl Example:
dnl
dnl AX_ARG_WITH_CHECK(libidn, AC_HELP_STRING([--with-libidn],[enable support
for the idn library]), have_libidn,
dnl [
dnl AC_CHECK_LIB(idn, idna_to_ascii_4i, have_libidn=yes, have_libidn=no)
dnl ],
dnl [
dnl LIBIDN="-lidn"
dnl AC_DEFINE_UNQUOTED(HAVE_LIBIDN, 1, [Define if you have libidn])
dnl ],
dnl [
dnl LIBIDN=
dnl ])
dnl AC_SUBST(LIBIDN)
dnl
dnl @author Gregorio Guidi <[EMAIL PROTECTED]>
dnl @version 2005-02-03
dnl @license AllPermissive
AC_DEFUN(AX_ARG_WITH_CHECK,
[AC_ARG_WITH([$1], [$2 @<:@default=check@:>@], , [with_]patsubst([$1], -,
_)=check)
if test "[x$with_]patsubst([$1], -, _)" != xno; then
$4
if test "x$[$3]" != xno; then
ifelse([$5], , :, [$5])
else
if test "[x$with_]patsubst([$1], -, _)" != xcheck; then
AC_MSG_ERROR([--with-[$1] was given, but test for [$1] failed])
fi
fi
fi
ifelse([$6], , , [if test "[x$with_]patsubst([$1], -, _)" = xno || test
"x$[$3]" = xno; then
$6
fi])])
dnl @synopsis AX_ARG_ENABLE_CHECK(FEATURE, HELP-STRING, RESULT-ID, TEST-SCRIPT,
ACTION-IF-TRUE [, ACTION-IF-FALSE])
dnl
dnl @summary Check for a feature and add a switch to force it on or off.
dnl
dnl This macro is used to peform a test on the availability
dnl of an internal feature, giving the user the possibility to
dnl explicitely enable or disable the feature through a
dnl configure switch.
dnl
dnl If the user gave `configure' the option `--enable-FEATURE',
dnl or no option was given, run commands TEST-SCRIPT, which
dnl are supposed to store the result in RESULT-ID. If the value
dnl of RESULT-ID is `no', the test is considered failed, and
dnl ACTION-IF-FALSE is run. Any other value is considered a
dnl success, and ACTION-IF-TRUE is run. If the user gave
dnl `--disable-FEATURE', ACTION-IF-FALSE is run. If the user
dnl gave `--enable-FEATURE' and the test failed, exit with an
dnl error.
dnl
dnl Example:
dnl
dnl AX_ARG_ENABLE_CHECK(internal-malloc,
AC_HELP_STRING([--enable-internal-malloc],[use own malloc implementation]),
ac_cv_internal_malloc,
dnl [
dnl AC_CACHE_CHECK([whether own malloc implementation can be used],
ac_cv_internal_malloc,
dnl [
dnl case $target_cpu in
dnl i?86)
dnl ac_cv_internal_malloc=yes;;
dnl *)
dnl ac_cv_internal_malloc=no;;
dnl esac
dnl ])
dnl ],
dnl [
dnl AC_DEFINE_UNQUOTED(USE_INTERNAL_MALLOC, 1, [Define to use internal
malloc implementation])
dnl ])
dnl
dnl @author Gregorio Guidi <[EMAIL PROTECTED]>
dnl @version 2005-02-03
dnl @license AllPermissive
AC_DEFUN(AX_ARG_ENABLE_CHECK,
[AC_ARG_ENABLE([$1], [$2 @<:@default=check@:>@], , [enable_]patsubst([$1], -,
_)=check)
if test "[x$enable_]patsubst([$1], -, _)" != xno; then
$4
if test "x$[$3]" != xno; then
ifelse([$5], , :, [$5])
else
if test "[x$enable_]patsubst([$1], -, _)" != xcheck; then
AC_MSG_ERROR([--enable-[$1] was given, but test for [$1] failed])
fi
fi
fi
ifelse([$6], , , [if test "[x$enable_]patsubst([$1], -, _)" = xno || test
"x$[$3]" = xno; then
$6
fi])])
_______________________________________________
Autoconf mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/autoconf
