Re: How can I enable option-checking from configure.ac 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 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
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
[GCC Help] [Kernel Discussion] [RPM Discussion] [Red Hat Development] [Yosemite News] [USB] [Samba]