RFE: macro for warning at configure-time if CFLAGS includes -Werror
I just helped someone debug an issue today where their configure run was getting weird results, because they had called './configure CFLAGS=-Wall -Werror -O0 -g', and the -Werror was causing several tests to guess wrong. This issue has repeatedly come up on this list, and our advice has always been don't use -Werror during configure; save it for 'make'. In fact, we even have examples to point to on how to write a configure script that will probe whether -Werror works and add it automatically at make time without also polluting the rest of the configure run (such as via coreutils' ./configure --enable-gcc-warnings, coupled with Makefile.am snippets to add -Werror to AM_CFLAGS as appropriate). For packages that already take care to separate out -Werror handling, I'm thinking it might be worthwhile to have a macro that would emit a warning at ./configure time if CC is detected as gcc, and CFLAGS contains -Werror, since this usually won't have the desired results. Of course, it would need to be a new macro (we don't want to change the behavior of configure to add a warning without explicit request by package maintainers), but it seems like something that enough packages would like to be worth including in the next autoconf release. It seems like such a macro should be called after AC_PROG_CC (need to know if the compiler is gcc). Thoughts? Does my idea make sense? What would a good macro name be? AC_PROG_CC_SUSPICIOUS_CFLAGS AC_PROG_CC_NO_WERROR -- 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: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On Wed, Sep 19, 2012 at 5:01 PM, Eric Blake ebl...@redhat.com wrote: I just helped someone debug an issue today where their configure run was getting weird results, because they had called './configure CFLAGS=-Wall -Werror -O0 -g', and the -Werror was causing several tests to guess wrong. This issue has repeatedly come up on this list, and our advice has always been don't use -Werror during configure; save it for 'make'. In fact, we even have examples to point to on how to write a configure script that will probe whether -Werror works and add it automatically at make time without also polluting the rest of the configure run (such as via coreutils' ./configure --enable-gcc-warnings, coupled with Makefile.am snippets to add -Werror to AM_CFLAGS as appropriate). For packages that already take care to separate out -Werror handling, I'm thinking it might be worthwhile to have a macro that would emit a warning at ./configure time if CC is detected as gcc, and CFLAGS contains -Werror, since this usually won't have the desired results. Of course, it would need to be a new macro (we don't want to change the behavior of configure to add a warning without explicit request by package maintainers), but it seems like something that enough packages would like to be worth including in the next autoconf release. It seems like such a macro should be called after AC_PROG_CC (need to know if the compiler is gcc). Thoughts? Does my idea make sense? What would a good macro name be? AC_PROG_CC_SUSPICIOUS_CFLAGS AC_PROG_CC_NO_WERROR The best solution for users is likely to be similar to do the sane thing so things work. If that means hding -Werror so things work as intended, that that is probably one of the better paths to take. As a dumb user, I want to use a cookbook. That means I want to do a: ./configure CFLAGS=-Wall -Wextra I don't want to have to learn how to use autoconf, automake, and make. I don't want to subscribe to mailing list to make things work. I just want it to work as expected. The dumb user (me) is likely not the same person who decided to use the tool chain (the maintainers). Maintainers are probably much more savvy users. No disrespect intended. Jeff ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
Jeffrey Walton noloa...@gmail.com writes: As a dumb user, I want to use a cookbook. That means I want to do a: ./configure CFLAGS=-Wall -Wextra I don't want to have to learn how to use autoconf, automake, and make. I don't want to subscribe to mailing list to make things work. I just want it to work as expected. If you're an end user following a cookbook, you probably should not be overriding the decisions of the package maintainer and adding additional warning flags. Warning flags are useful for more sophisticated users to detect possible bugs in the software. Users who are just following cookbooks and who aren't prepared to debug the software are not going to gain anything useful by enabling a bunch of optional warnings, let alone trying to use -Werror. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 09/19/2012 03:14 PM, Jeffrey Walton wrote: On Wed, Sep 19, 2012 at 5:01 PM, Eric Blake ebl...@redhat.com wrote: I just helped someone debug an issue today where their configure run was getting weird results, because they had called './configure CFLAGS=-Wall -Werror -O0 -g', and the -Werror was causing several tests to guess wrong. The best solution for users is likely to be similar to do the sane thing so things work. If that means hding -Werror so things work as intended, that that is probably one of the better paths to take. That would be more invasive; I really don't want to change AC_PROG_CC itself for fear of breaking backwards compatibility for users unprepared for configure to hide -Werror from the rest of make. Blindly ignoring -Werror might trigger its own problems (I know of at least one situation where the configure.ac writer intentionally wanted to test whether a particular library header triggered warnings, to know whether it was safe to use -Werror elsewhere in the project; silently stripping -Werror from CFLAGS for the duration of configure would make this situation harder to probe for). In other words, you generally want to configure for the exact environment that make will also be using, and hiding -Werror means you have two different environments. On the other hand, the rest of your project is generally written in decent coding style, while configure tests tend to be bare bones abuse to intentionally probe what features are available, and therefore more likely to trigger warnings. So maybe your idea has merit, and in fact, I think the two ideas are orthogonal and could both be implemented (although configure.ac writers would only ever need to use one of the two versions). As a dumb user, I want to use a cookbook. That means I want to do a: ./configure CFLAGS=-Wall -Wextra I don't want to have to learn how to use autoconf, automake, and make. I don't want to subscribe to mailing list to make things work. I just want it to work as expected. For this to work, we'd need a way for the configure.ac author to state that temporary -Werror scrubbing during configure is okay, by invoking a macro _prior_ to AC_PROG_CC. If that macro has been used, then AC_PROG_CC would record whether -Werror is present, strip it from CFLAGS (or better, morph it to -Wno-error, so that the edit can be undone later even if CFLAGS has been appended to by the rest of configure), run the rest of configure without error checking, and then at the end, re-instate CFLAGS back to the user's request. The dumb user (me) is likely not the same person who decided to use the tool chain (the maintainers). Maintainers are probably much more savvy users. No disrespect intended. None taken. However, I still think that this is enough of a change in default behavior that it has to be something that configure.ac authors have to request, rather than something forced on them by default, since not all packages behave equally in the presence or absence of -Werror. And again, my original proposal, when given your use case as a user, would result in something like: $ ./configure CFLAGS=-Wall -Werror warning: -Werror detected in configure-time CFLAGS; if this does not work the way you expected, then configure without CFLAGS and later run 'make CFLAGS=-Werror' That does not mean that the end user has to know anything about touching configure.ac or rerunning autoconf. Of course, I'm arguing that _someone_ has to originally touch configure.ac before either my proposed warning or your proposed -Werror sanitizing can take place at configure time, but that one-time edit really is a maintainer's role. -- 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: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 09/19/2012 03:33 PM, Adrian Bunk wrote: IMHO the best solution for both package maintainers and people compiling software would be: - AC_PROG_CC always filters out -Werror Always filtering seems a bit too strong - I think that filtering -Werror requires at least some request from the configure.ac writer that filtering -Werror is intended. - when -Werror was filtered out, configure prints a message like filtering out -Werror during configure - when -Werror was filtered out, AC_OUTPUT re-adds it Indeed, this is what I would do if the filtering were done. But maybe I can be convinced that always filtering -Werror from user-input CFLAGS for the duration of configure makes sense, and agree with changing AC_PROG_CC to do this automatically instead of requiring configure.ac consent to the filtering. At this point, patches would speak louder than words (that goes for me, as well, since I sparked the debate without any proposed patch). -- 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: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On Wed, Sep 19, 2012 at 03:01:24PM -0600, Eric Blake wrote: I just helped someone debug an issue today where their configure run was getting weird results, because they had called './configure CFLAGS=-Wall -Werror -O0 -g', and the -Werror was causing several tests to guess wrong. This issue has repeatedly come up on this list, and our advice has always been don't use -Werror during configure; save it for 'make'. In fact, we even have examples to point to on how to write a configure script that will probe whether -Werror works and add it automatically at make time without also polluting the rest of the configure run (such as via coreutils' ./configure --enable-gcc-warnings, coupled with Makefile.am snippets to add -Werror to AM_CFLAGS as appropriate). That doesn't solve the problem of how to add -Werror when compiling the typical autoconf-using software that does not have any specific warning handling implemented. For packages that already take care to separate out -Werror handling, I'm thinking it might be worthwhile to have a macro that would emit a warning at ./configure time if CC is detected as gcc, and CFLAGS contains -Werror, since this usually won't have the desired results. Of course, it would need to be a new macro (we don't want to change the behavior of configure to add a warning without explicit request by package maintainers), but it seems like something that enough packages would like to be worth including in the next autoconf release. It seems like such a macro should be called after AC_PROG_CC (need to know if the compiler is gcc). Thoughts? Does my idea make sense? What would a good macro name be? AC_PROG_CC_SUSPICIOUS_CFLAGS AC_PROG_CC_NO_WERROR IMHO the best solution for both package maintainers and people compiling software would be: - AC_PROG_CC always filters out -Werror - when -Werror was filtered out, configure prints a message like filtering out -Werror during configure - when -Werror was filtered out, AC_OUTPUT re-adds it cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On Wed, Sep 19, 2012 at 5:22 PM, Russ Allbery r...@stanford.edu wrote: Jeffrey Walton noloa...@gmail.com writes: As a dumb user, I want to use a cookbook. That means I want to do a: ./configure CFLAGS=-Wall -Wextra I don't want to have to learn how to use autoconf, automake, and make. I don't want to subscribe to mailing list to make things work. I just want it to work as expected. If you're an end user following a cookbook, you probably should not be overriding the decisions of the package maintainer and adding additional warning flags. Warning flags are useful for more sophisticated users to detect possible bugs in the software. Users who are just following cookbooks and who aren't prepared to debug the software are not going to gain anything useful by enabling a bunch of optional warnings, let alone trying to use -Werror. Good point Russ. I would like to leave it alone. But *every* FOSS project I've seen (and *all* closed source security audits I've performed) neglect the security related stuff. That means I have to act because the supply chain in under my purview - I have no choice. Here's the latest example of high integrity software failing the CompSci 101 stuff. But its not limited to high-integrity software (the problem is pandemic): FreeRADIUS​: Stack Overflow in TLS-based EAP Methods, http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3547. In the above example, at least three measures could have been taken to avoid or lessen the problem. If you look at the project's default setup, you will see the development team chooose none of them. In this case, it was not the development team making a careful choice. It was as oversight (as I said, the awareness problem is pandemic). Jeff ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On Wed, Sep 19, 2012 at 03:40:39PM -0600, Eric Blake wrote: On 09/19/2012 03:33 PM, Adrian Bunk wrote: IMHO the best solution for both package maintainers and people compiling software would be: - AC_PROG_CC always filters out -Werror Always filtering seems a bit too strong - I think that filtering -Werror requires at least some request from the configure.ac writer that filtering -Werror is intended. ... But that wouldn't fix your original problem where a normal configure had wrong test results with -Werror. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 09/19/2012 04:02 PM, Adrian Bunk wrote: On Wed, Sep 19, 2012 at 03:40:39PM -0600, Eric Blake wrote: On 09/19/2012 03:33 PM, Adrian Bunk wrote: IMHO the best solution for both package maintainers and people compiling software would be: - AC_PROG_CC always filters out -Werror Always filtering seems a bit too strong - I think that filtering -Werror requires at least some request from the configure.ac writer that filtering -Werror is intended. ... But that wouldn't fix your original problem where a normal configure had wrong test results with -Werror. Huh? Filtering _would_ fix the original problem of getting wrong configure results under -Werror, because -Werror wouldn't be used during configure. It's just a question of whether it is safe to filter by default, or whether filtering is enough of a change to require a one-line addition to configure.ac explicitly requesting the filtering. -- 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: RFE: macro for warning at configure-time if CFLAGS includes -Werror
Jeffrey Walton noloa...@gmail.com writes: I would like to leave it alone. But *every* FOSS project I've seen (and *all* closed source security audits I've performed) neglect the security related stuff. That means I have to act because the supply chain in under my purview - I have no choice. Ah, okay, yes, that's a good point. But -Werror (apart from the one specifically about format options, which configure probes don't trigger so far as I know) is not particularly useful from a security perspective. And even the one for format options doesn't make the software build more secure; it's a debugging tool to find potential security problems. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
FWIW my opinion as maintainer of several autoconf-using packages is that it really should be my decision if -Werror given by user is passed to configure tests. However, default could be either way - l just need power to override that. I have at least one test that should fail if -Werror is going to be used in real software compilation and the tested thing is giving warnings. - ML ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On Wed, Sep 19, 2012 at 04:06:08PM -0600, Eric Blake wrote: On 09/19/2012 04:02 PM, Adrian Bunk wrote: On Wed, Sep 19, 2012 at 03:40:39PM -0600, Eric Blake wrote: On 09/19/2012 03:33 PM, Adrian Bunk wrote: IMHO the best solution for both package maintainers and people compiling software would be: - AC_PROG_CC always filters out -Werror Always filtering seems a bit too strong - I think that filtering -Werror requires at least some request from the configure.ac writer that filtering -Werror is intended. ... But that wouldn't fix your original problem where a normal configure had wrong test results with -Werror. Huh? Filtering _would_ fix the original problem of getting wrong configure results under -Werror, because -Werror wouldn't be used during configure. It's just a question of whether it is safe to filter by default, or whether filtering is enough of a change to require a one-line addition to configure.ac explicitly requesting the filtering. My point is that a normal configure uses whatever is the default, and will always use the default. That is the common case, and any fancy warning and -Werror handling in confiugre.ac is a special case. And if the default is not to filter, chances are that the person whom you helped debugging would still have come to you with the same problem if he'd had tried the -Werror in 10 years for the first time. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
Just off the top of my head, what about an AC_GCC_FILTER_WERROR macro that would search for an incoming -Werror and remove it if it was provided and restore it at the end? The downside of this is that maintainers would still have to know to add it. And I recall seeing a number of stable GNU packages that hadn't been updated in a while. This may no longer be the case, but I know I wanted to see these packages upgrade to newer auto* tools just for the features the newer auto* tools offered. H ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 20 September 2012 01:12, Marko Lindqvist cazf...@gmail.com wrote: FWIW my opinion as maintainer of several autoconf-using packages is that it really should be my decision if -Werror given by user is passed to configure tests. However, default could be either way - l just need power to override that. I have at least one test that should fail if -Werror is going to be used in real software compilation and the tested thing is giving warnings. Actually, *other* tests in the same configure script will give wrong results if -Werror passed, so ideally it should be easy to give -Werror for that single test only. So maybe filtering by default but storing information whether -Werror was part of original CFLAGS (CXXFLAGS, CPPFLAGS?) to documented variable or other part of official API for configure.ac author to reinstate -Werror at will. This leaves me just wrapping my head around what will happen to other variables with values based on contents of CFLAGS while it was filtered, and does it even matter. - ML ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 09/19/2012 04:18 PM, Adrian Bunk wrote: Huh? Filtering _would_ fix the original problem of getting wrong configure results under -Werror, because -Werror wouldn't be used during configure. It's just a question of whether it is safe to filter by default, or whether filtering is enough of a change to require a one-line addition to configure.ac explicitly requesting the filtering. My point is that a normal configure uses whatever is the default, and will always use the default. That is the common case, and any fancy warning and -Werror handling in confiugre.ac is a special case. Those are special cases that _I, as configure.ac author,_ get to choose whether they should happen. If I know that -Werror filtering won't impact my package, then I add one line to my configure.ac, and then 10 years from now, when the user first tries './configure CFLAGS=-Werror', the default _for my package_ already handles it sanely. It's just that I don't know whether _autoconf_ can enforce filtering on ALL packages, or whether -Werror handling has to be an opt-in decision by individual package authors. Either way, once filtering is enabled for my package, then people will quit coming to me when they attempt to configure my package with -Werror. -- 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: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 09/19/2012 04:30 PM, Marko Lindqvist wrote: On 20 September 2012 01:12, Marko Lindqvist cazf...@gmail.com wrote: FWIW my opinion as maintainer of several autoconf-using packages is that it really should be my decision if -Werror given by user is passed to configure tests. However, default could be either way - l just need power to override that. I have at least one test that should fail if -Werror is going to be used in real software compilation and the tested thing is giving warnings. Actually, *other* tests in the same configure script will give wrong results if -Werror passed, so ideally it should be easy to give -Werror for that single test only. I think you meant some tests will give wrong results if user-requested -Werror is filtered. So maybe filtering by default but storing information whether -Werror was part of original CFLAGS (CXXFLAGS, CPPFLAGS?) to documented variable or other part of official API for configure.ac author to reinstate -Werror at will. Indeed, we may end up documenting: AC_PROG_CC_FILTER_WERROR AC_PROG_CC to enable filtering mode (or perhaps a new optional second argument to AC_PROG_CC([search list], [filter-werror]) that sets options as part of AC_PROG_CC), and then the ability to undo that filtering on a per-test basis, by adding a new optional fourth argument to AC_COMPILE_IFELSE([code], [if-true], [if-false], [undo-filter]) and friends. This leaves me just wrapping my head around what will happen to other variables with values based on contents of CFLAGS while it was filtered, and does it even matter. That's why I'm thinking that filtering -Werror has to be a conscious decision in configure.ac, and not the default enforced by stock autoconf. -- 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: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 09/19/2012 04:12 PM, Marko Lindqvist wrote: FWIW my opinion as maintainer of several autoconf-using packages is that it really should be my decision if -Werror given by user is passed to configure tests. However, default could be either way - l just need power to override that. I have at least one test that should fail if -Werror is going to be used in real software compilation and the tested thing is giving warnings. Agreed; I will also point out that the suggestion right now is to filter -Werror out of user-passed CFLAGS at compiler-detection time (ie. a one-time filter at AC_PROG_CC, not a per-compiler-run at AC_COMPILE_IFELSE), and therefore the rest of configure is free to (temporarily) re-add it to CFLAGS without that temporary change also being filtered. Then, after all configure checks have run, the user-requested flag will be restored to the CFLAGS passed on to make, along with any entries appended to CFLAGS during the course of configure. -- 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: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On Thu, 20 Sep 2012, Adrian Bunk wrote: IMHO the best solution for both package maintainers and people compiling software would be: - AC_PROG_CC always filters out -Werror - when -Werror was filtered out, configure prints a message like filtering out -Werror during configure - when -Werror was filtered out, AC_OUTPUT re-adds it If this is done, there will be a compilation error when there is a warning, regardless of the cause of the warning. That is what was requested but it might not be what was desired if a system header produces the warning. The result might fail immediately. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror
On 09/19/2012 04:49 PM, Bob Friesenhahn wrote: On Thu, 20 Sep 2012, Adrian Bunk wrote: IMHO the best solution for both package maintainers and people compiling software would be: - AC_PROG_CC always filters out -Werror - when -Werror was filtered out, configure prints a message like filtering out -Werror during configure - when -Werror was filtered out, AC_OUTPUT re-adds it If this is done, there will be a compilation error when there is a warning, regardless of the cause of the warning. That is what was requested but it might not be what was desired if a system header produces the warning. The result might fail immediately. Yes, but it would fail at make time _because_ the user requested -Werror, and has buggy system headers; we honored the user's request, to the point that the user's request is possible, without getting false results during configure. And, as has been pointed out elsewhere in the flag, if there is an ability to do a per-compile undo of the filtering, it will even be possible to write configure tests to detect such buggy system headers in advance. -- 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
