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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 03/19/2012 09:05 AM, Hans-Peter Nilsson wrote:
>> From: Nick Bowler <nbowler@xxxxxxxxxxxxxxxx>
>> 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, 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)

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

#if 0

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

> 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   eblake@xxxxxxxxxx    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

Autoconf mailing list

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [USB]     [Samba]
  Powered by Linux