On 09/22/2014 10:07 AM, David A. Wheeler wrote: > On Mon, 22 Sep 2014 08:51:52 -0600, Eric Blake <eblake@xxxxxxxxxx> wrote: >> I don't think what you are asking for is possible. Either you want to >> use extensions (and just use the macro) or you don't. I don't really >> see a use case for wanting extensions on only some of the builds. > > I want to write code that will *use* extensions where available, but will portably run on > systems that don't have the extensions. Various parts need to detect the > presence of some extensions, and then provide alternatives when they're > not available. Of course, that means I need to able to *test* the alternatives. Except that the intent of AC_USE_SYSTEM_EXTENSIONS is basically "enable the exposure of all known extensions on all systems, so that all later tests can probe for individual features regardless of whether they are an extension that needs to be enabled to have a successful probe". Your program will portably run on all systems if you don't use extensions, and if you DO use extensions, then you STILL have to test on a per-feature basis WHICH extensions are available on the given system. At which point, it is STILL easier to just enable ALL extensions and then do per-feature testing, than it is to try and make the enablement of extensions be conditional. > > Thus, I want to be able to easily *disable* > extensions & then see if the code compiles/links/runs correctly. > My intent was to add a simple configure flag to disable extensions, to enable > some basic testing in those cases. That particular use case (explicitly having a mode that disables extensions even when compiling on a system like GNU/Linux that normally enables quite a bit) is seldom used in practice, but if it is something that you really want, I would not be opposed to a patch to make it easier to achieve. Bear in mind, though, that many systems pollute the namespace by default; a system that is strictly limited to a standards-comformant environment and which errors out on attempts to use extensions is hard to find. -- 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