On 02/26/2014 11:12 PM, Fredrik Tolf wrote: > >> Yes, it really is bad practice to mix compilation tests before turning >> extensions with compilation tests done afterwards. Turning on >> extensions is such a drastic change to the compilation environment that >> you want ALL your tests to run under the same environment. Either you >> plan on using extensions, and should enable them unconditionally up >> front, or you do not need extensions, and should not use the macro. > > Hm. I see your reasoning, and I see where you're coming from. However, > on FreeBSD, I don't actually have to turn on any extensions to use the > corresponding functionality (funopen &c.). Isn't it ugly, then, to > always enable system extensions, regardless of environment? No. Most programs WANT to blindly turn on all extensions, regardless of environment, because it is easier to write programs that can take advantage of extensions, regardless of how cavalier the system is about namespace pollution even when extensions are not requested. I could argue that FreeBSD has a bug in that it is not strictly POSIX compliant if funopen() is exposed by default when requesting POSIX compliant, but when extensions are requested, the namespace pollution of exposing funopen() is reasonable (but I'd actually have to test compilation on FreeBSD when my C source pre-defines _POSIX_C_SOURCE prior to including system headers, to determine whether funopen() is actually leaked when requesting strict compliance). There is a small set of projects that really DOES want to remain completely POSIX-compliant (or even stricter ANSI-C compliant) - those programs do NOT want to request extensions by default, so that they minimize namespace pollution from system headers. But they tend to be the minority. In my own experience, projects that use gnulib almost always end up using AC_USE_SYSTEM_EXTENSIONS under the hood, because gnulib is best able to implement lots of functionality when it can rely on system extensions. -- 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
