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 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 eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
