On 03/07/2014 02:07 PM, Bob Friesenhahn wrote: > On Fri, 21 Feb 2014, Eric Blake wrote: > >> This will still remain true. And the developer's choice of CFLAGS >> should always take precedence over any default flags that autoconf >> probes for in the absence of a developer preference. > > This statement is one that I definitely believe in but it makes the > grave assumption that it is possible to undo/override options specified > in left to right order. This works for GCC but definitely not compilers > at large. How would compilers be supported which do not provide the > ability to remove an already supplied option? Probably how we already handle non-default CFLAGS: If CFLAGS is unspecified, we choose defaults for you (currently '-g -O2' for gcc and '-g' for other compilers - this proposal adds several '-W...' for gcc and various other tested-to-work options for other compilers). But if you specify CFLAGS we honor your choice completely (and don't try to inject our defaults) Maybe there's some fine-tuning involved - we compute the default warnings, and stick it on the left of CFLAGS even if you explicitly override CFLAGS, but provide yet another envvar or command line option to disable all warnings probes; although for warnings to work by default this secondary variable has to eventually feed CFLAGS (because any other solution would require using a new variable in makefiles, which means its no longer a default-on improvement to the toolchain). There's also two levels of defaults - one is whether configure files should start probing for warnings by default (configure.ac authors should have final say on probing for additional warnings or bypassing the warning probes altogether, in the case where they don't like autoconf defaults), another at the end user level (configure users should have final say on whether to trust the configure.ac choice of CFLAGS, or to provide their own). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
