Re: AC_ARG_ENABLE and checking for unrecognized switches
> "Bob" == Bob Friesenhahn writes: Bob> A project can be made subordinate to another project without the Bob> author of the subordinate project being aware of it. This is a very Bob> useful capability. This capability is used by projects such as GCC. Yeah, but the outer configure script could easily pass --disable-option-checking. Maybe it already does. So, if the default is to suppress checking (as was reported), then that seems backward. More generally it would be nice if the outer configure would do some kind of global checking, and if --help reflected the actual state of what is available. This stuff comes up all the time for gdb, which does subdir configures like this: users either typo an option or are confused because --help doesn't mention the option we ask them to pass. Tom
Re: AC_ARG_ENABLE and checking for unrecognized switches
On Fri, 2019-03-15 at 14:35 -0700, Kip Warner wrote: > On Fri, 2019-03-15 at 16:24 -0500, Bob Friesenhahn wrote: > > A project can be made subordinate to another project without > > the author of the subordinate project being aware of it. This is a > > very useful capability. This capability is used by projects such > > as > > GCC. > > Hey Bob, > > > The Autotools philosophy is to provide as much freedom as possible > > to the end user while working in a consistent way. This would > > include the case where a project is created which builds several > > other projects. > > In this case my project isn't subordinate to any other. It also has > no subprojects such that the root configure.ac invokes child ones. > There's not even child Makefile.am's. I also just found out that enable_option_checking is by default set to "no", which appears to be contrary to what the Autoconf manual says. -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: AC_ARG_ENABLE and checking for unrecognized switches
On Fri, 2019-03-15 at 16:24 -0500, Bob Friesenhahn wrote: > A project can be made subordinate to another project without > the author of the subordinate project being aware of it. This is a > very useful capability. This capability is used by projects such as > GCC. Hey Bob, > The Autotools philosophy is to provide as much freedom as possible > to the end user while working in a consistent way. This would > include the case where a project is created which builds several > other projects. In this case my project isn't subordinate to any other. It also has no subprojects such that the root configure.ac invokes child ones. There's not even child Makefile.am's. -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: AC_ARG_ENABLE and checking for unrecognized switches
On Fri, 15 Mar 2019, Kip Warner wrote: https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Option-Checking.html My reading is that there *is* checking by default, but it is turned off if you have a subdir configure, but then can be turned back on again by the user. Good eye, Tom. The only problem here is my configure.ac doesn't use a AC_CONFIG_SUBDIRS because there are no child configure.ac scripts to run, so by default that checking should have been enabled. It's possible I could be doing something wrong though. A project can be made subordinate to another project without the author of the subordinate project being aware of it. This is a very useful capability. This capability is used by projects such as GCC. The Autotools philosophy is to provide as much freedom as possible to the end user while working in a consistent way. This would include the case where a project is created which builds several other projects. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: AC_ARG_ENABLE and checking for unrecognized switches
On Fri, 2019-03-15 at 07:02 -0600, Tom Tromey wrote: > I think there are a few wrinkles: > > https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Option-Checking.html > > My reading is that there *is* checking by default, but it is turned > off if you have a subdir configure, but then can be turned back on > again by the user. Good eye, Tom. The only problem here is my configure.ac doesn't use a AC_CONFIG_SUBDIRS because there are no child configure.ac scripts to run, so by default that checking should have been enabled. It's possible I could be doing something wrong though. -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: AC_ARG_ENABLE and checking for unrecognized switches
>> I use AC_ARG_ENABLE to create a number of different --enable switches. >> I noticed when I accidentally mistyped the in --enable- >> , ./configure didn't bail on the unrecognized switch. Eric> This is by design; the GNU Coding Standards wants projects to be Eric> aggregatable, such that someone else could write a larger project that Eric> uses yours as a subdirectory, and takes additional --enable switches Eric> that some (but not all) of its subprojects understand. Being able to Eric> blindly pass down all of its switches to subprojects, without having to Eric> worry about which projects care about which switches, makes this easier. I think there are a few wrinkles: https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Option-Checking.html My reading is that there *is* checking by default, but it is turned off if you have a subdir configure, but then can be turned back on again by the user. Doing something better here would be nice (though maybe difficult) since in my experience I often forget the exact spelling... like, is it "--disable-multilib" or "--disable-multilibs"? Or is it "--with-python" or "--enable-python"? Tom
Re: AC_ARG_ENABLE and checking for unrecognized switches
On Thu, 2019-03-14 at 23:27 -0500, Eric Blake wrote: > Unfortunately, since it is by design that unknown --enable arguments > are ignored, I don't know of a handy way to switch that behavior to > warn or fail instead. Thanks anyways Eric. -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: AC_ARG_ENABLE and checking for unrecognized switches
On 3/14/19 10:56 PM, Kip Warner wrote: > Hey list, > > I use AC_ARG_ENABLE to create a number of different --enable switches. > I noticed when I accidentally mistyped the in --enable- > , ./configure didn't bail on the unrecognized switch. This is by design; the GNU Coding Standards wants projects to be aggregatable, such that someone else could write a larger project that uses yours as a subdirectory, and takes additional --enable switches that some (but not all) of its subprojects understand. Being able to blindly pass down all of its switches to subprojects, without having to worry about which projects care about which switches, makes this easier. > > Is there something I need to add to configure.ac in order to get it to > do this? Unfortunately, since it is by design that unknown --enable arguments are ignored, I don't know of a handy way to switch that behavior to warn or fail instead. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
AC_ARG_ENABLE and checking for unrecognized switches
Hey list, I use AC_ARG_ENABLE to create a number of different --enable switches. I noticed when I accidentally mistyped the in --enable- , ./configure didn't bail on the unrecognized switch. Is there something I need to add to configure.ac in order to get it to do this? -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
