Re: How can I enable option-checking from configure.ac after it being default-disabled?

[Nick Bowler]

Hello Hans-Peter,

On 2012-03-19 16:05 +0100, Hans-Peter Nilsson wrote:
> > From: Nick Bowler <address@hidden>
> > Date: Mon, 19 Mar 2012 14:51:25 +0100
> 
> > 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.
> 
> > > 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.
> 
> Are you re-stating what I mentioned above or does it disable
> option-checking in a different way than I mentioned?
> (I realise that "call" here is AC_CONFIG_SUBDIRS being expanded,
> not the resulting shell-code being executed.)

You didn't seem to address _how_ option checking gets disabled in your
mail (other than a mention of it having something to do with
AC_CONFIG_SUBDIRS).  I intended to make it clear that it is the
expansion ("call") of AC_CONFIG_SUBDIRS which directly causes this to
happen.

> >  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.
> 
> But is this considered a cleaner way than getting that effect
> through the never-executed idiom I used above?

Well, I was under the impression from your mail that your "never-
executed idiom" didn't actually work.  Your approach does not rely on
any internal details of autoconf, so in that sense it's "cleaner", but
if it doesn't work...

> And more importantly, will your idiom have the desired effect:
> not disable option-checking by default?  (The answer may be
> obvious to you autoconfers.)

What the code above does is to temporarily (sorry, I clearly failed at
spelling that word in the comment) replace the definition of
AC_CONFIG_SUBDIRS with one that expands to nothing.  (pushdef and popdef
are M4 builtins for doing this) Since it expands to nothing (and thus
its expansion does nothing), it will not disable option checking.  It
also will not emit any code to perform the recursive configure call
(since it expands to nothing), so your "if false" construct can go away
as well.

Now, the reason this works at all is because autoreconf decides what
do do based on the M4 traces, which record the names and arguments of
macros that get called.  Autoreconf cannot tell the difference between
this "fake" AC_CONFIG_SUBDIRS and the real one, so it will recurse as
intended.

Other programs that check the traces for AC_CONFIG_SUBDIRS will be
similarly duped, which may or may not be desirable in your case.

Hope that helps,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)