Re: How can I enable option-checking from configure.ac after it being default-disabled?
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. I had expected to find either an option to AC_DISABLE_OPTION_CHECKING, e.g. something like AC_DISABLE_OPTION_CHECKING([false]), or alternatively and more intuitively than two negatives IMHO; something like AC_OPTION_CHECKING(whichever). A quick grep for OPTION_CHECKING in the autoconf git repo didn't find me any new construct to achieve this. So, can I have a way to turn *on* option-checking by default from configure.ac and regardless of AC_CONFIG_SUBDIRS, please? Why this odd request? In RAPP, http://savannah.nongnu.org/projects/rapp (feel very welcome to 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. 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. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to determine -rdyamic / -Wl,--export-dynamic flags?
On 03/18/12 17:10, Paul Smith wrote: Does anyone have a macro that will correctly determine when -rdynamic and/or -Wl,--export-dynamic can be used? I'm not using libtool but I'd like my application to be built such that functions in it can be invoked by dynamically loaded objects. I saw http://www.mail-archive.com/autoconf@gnu.org/msg15247.html but there was no definitive response... has anyone come up with something since then? I'd prefer to not invoke a test executable, to preserve cross-compiling. Thanks! Paul, I think you're not getting a response because you're asking a lot. Without testing by running an executable, this can't be determined behaviorally, so your best bet is some sort of lookup. I would suggest you write your own macro, where you set the flag based on known system information, and barring that try some link-time flags and use one that doesn't generate any errors. HTH, Robert ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How can I enable option-checking from configure.ac after it being default-disabled?
On 03/19/2012 04:16 PM, Eric Blake wrote: 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). Option checking presumes all config-subdirs configure scripts are accepting the same set of configure-options. This doesn't always apply and even less applies in cases of optional config-subdirs, esp. in cases when config-subdirs originate from different origins and are being treated as optional drop-in packages. Ralf ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How can I enable option-checking from configure.ac after it being default-disabled?
Hello Hans-Peter, On 2012-03-19 16:05 +0100, Hans-Peter Nilsson wrote: From: Nick Bowler nbow...@elliptictech.com 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@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How can I enable option-checking from configure.ac after it being default-disabled?
From: Eric Blake ebl...@redhat.com Date: Mon, 19 Mar 2012 16:16:46 +0100 On 03/19/2012 09:05 AM, Hans-Peter Nilsson wrote: 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; (As intended.) but some macro expansions have side effects that may cause execution in other places of configure. I see. m4_pushdef([AC_CONFIG_SUBDIRS], []) AC_CONFIG_SUBDIRS([test/installtest]) m4_popdef([AC_CONFIG_SUBDIRS]) 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. Ok, thanks! And more importantly, will your idiom have the desired effect: not disable option-checking by default? (The answer may be obvious to you autoconfers.) Silly me for not just testing; it does, thanks. Meta-question: Why are you disabling option-checking in the first place? Missing a negation? It's contrary to GNU Coding Standards (JFTR: I don't see support for that statement at http://www.gnu.org/prep/standards/, just an incidental observation.) (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). But I don't *want* to disable option-checking, that's just what happens when I have AC_CONFIG_SUBDIR! If I could, I'd explicitly enable it; the point of this request! brgds, H-P ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How can I enable option-checking from configure.ac after it being default-disabled?
On 03/19/2012 09:48 AM, Hans-Peter Nilsson wrote: Meta-question: Why are you disabling option-checking in the first place? Missing a negation? Perhaps. That's the problem with double negatives. A better wording might be: Since option checking ignores unknown options by default, why are you explicitly trying to enable option checking? It's contrary to GNU Coding Standards (JFTR: I don't see support for that statement at http://www.gnu.org/prep/standards/, just an incidental observation.) https://www.gnu.org/prep/standards/standards.html#Configuration All configure scripts should accept all of the “detail” options and the variable settings, whether or not they make any difference to the particular package at hand. In particular, they should accept any option that starts with ‘--with-’ or ‘--enable-’. This is so users will be able to configure an entire GNU source tree at once with a single set of options. (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). But I don't *want* to disable option-checking, that's just what happens when I have AC_CONFIG_SUBDIR! If I could, I'd explicitly enable it; the point of this request! Again, sorry for my poor wording - the ability to enable the rejection of unknown options is what is contrary to GCS, and yet it is this explicit enabling of rejecting unknown options that you are trying to accomplish. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How can I enable option-checking from configure.ac after it being default-disabled?
From: Eric Blake ebl...@redhat.com Date: Mon, 19 Mar 2012 16:59:59 +0100 https://www.gnu.org/prep/standards/standards.html#Configuration I guess I just couldn't read. :( Again, sorry for my poor wording - the ability to enable the rejection of unknown options is what is contrary to GCS, and yet it is this explicit enabling of rejecting unknown options that you are trying to accomplish. (I blame an old emacs bug for dropping the CC to the list in my reply to nbowler, sorry:) I recognize this, but also think the GCS should help with defaults rather than definitely enforce here; an option from configure.ac to explicitly set whether option-checking is wanted still IMHO seems in order, as a way to override the default. brgds, H-P ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
