autoconf
[Top][All Lists]
Advanced

[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: Eric Blake
Subject: Re: How can I enable option-checking from configure.ac after it being default-disabled?
Date: Mon, 19 Mar 2012 09:16:46 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

On 03/19/2012 09:05 AM, 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

Any expansion of this macro that is executed in place will be skipped at
configure time; but some macro expansions have side effects that may
cause execution in other places of configure.


>> 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])

Whereas this idiom completely disables the macro at m4 time - the only
thing left is that the macro still gets traced with a particular
argument.  That is, anyone (like autoreconf) that relies on the trace
output to see which directories to visit will still work.

>>
>> 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?

It _is_ cleaner to disable things earlier in the code generation cycle.
 The difference can be compared to C code idioms.  Your shell code
approach is like a runtime conditional:

if (false)
  config_subdir("test/installtest")

vs. the m4_pushdef() approach as a compile-time conditional:

#if 0
  config_subdir("test/installtest")
#endif

except that with m4_pushdef(), autoconf --trace still sees that you
called AC_CONFIG_SUBDIR.

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

Meta-question: Why are you disabling option-checking in the first place?
 It's contrary to GNU Coding Standards (the ability to disable option
checking is provided for non-GNU packages, but doesn't get as much
testing because GNU packages shouldn't be using it in the first place).

> 
> I forgot to mention the fun-and-anecdotal part: stating
> --enable-debugging instead of --enable-debug (not looking at the
> build-log) and wondering why the debugging info was so
> optimized-out; mis-remembering that I should be getting errors
> for unsupported configure-options because of observations
> *before* adding the non-call to AC_CONFIG_SUBDIRS. :) (Now I've
> "solved" this supposedly-common mistake by erroring out for
> AC_ARG_ENABLE([debugging]).)

Interesting approach to specifically error out for common mis-spellings,
when you can't generically reject all typos.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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