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]|
Hello Hans-Peter, On 2012-03-19 16:05 +0100, 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 > > > > 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/) _______________________________________________ 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]