[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How can I enable option-checking from configure.ac after it being de
From: |
Nick Bowler |
Subject: |
Re: How can I enable option-checking from configure.ac after it being default-disabled? |
Date: |
Mon, 19 Mar 2012 09:51:25 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On 2012-03-18 18:24 +0100, Hans-Peter Nilsson wrote:
> Hi. I don't see a way to turn on option-checking after it being
> disabled-by-default due to AC_CONFIG_SUBDIRS. I had expected to
> find either an option to AC_DISABLE_OPTION_CHECKING,
> e.g. something like AC_DISABLE_OPTION_CHECKING([false]), or
> alternatively and more intuitively than two negatives IMHO;
> something like AC_OPTION_CHECKING(whichever). A quick grep for
> OPTION_CHECKING in the autoconf git repo didn't find me any new
> construct to achieve this.
>
> So, can I have a way to turn *on* option-checking by default
> from configure.ac and regardless of AC_CONFIG_SUBDIRS, please?
>
> Why this odd request? In RAPP,
> <http://savannah.nongnu.org/projects/rapp> (feel very welcome to
> have a look at its configure.ac), there's the hopefully
> self-explanatory:
>
> # The directory test/installtest isn't configured until after
> # installation, but to make autoreconf update this directory we
> # have to mention it here
> if false; then
> AC_CONFIG_SUBDIRS([test/installtest])
> fi
It is actually the call to AC_CONFIG_SUBDIRS which disables option
checking. Since you're only doing this to make autoreconf recurse into
the subdirectory, and don't actually care about the expansion of
AC_CONFIG_SUBDIRS, you can fool autoreconf into thinking you called
AC_CONFIG_SUBDIRS without actually doing so.
For example:
dnl Fool autoreconf into thinking we called AC_CONFIG_SUBDIRS here by
dnl temporily suppressing its definition.
m4_pushdef([AC_CONFIG_SUBDIRS], [])
AC_CONFIG_SUBDIRS([test/installtest])
m4_popdef([AC_CONFIG_SUBDIRS])
This is (ab)using internal details of autoreconf, thus it might not be
guaranteed to work in the future.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)