autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] Modernize header checks


From: Peter Rosin
Subject: Re: [PATCH 0/2] Modernize header checks
Date: Sat, 01 Jun 2013 08:13:52 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

On 2013-05-31 23:46, Eric Blake wrote:
> On 05/31/2013 03:26 PM, Peter Rosin wrote:
>> On 2013-05-31 19:19, Eric Blake wrote:
>>> That said, would it hurt if autoconf just unconditionally defined the
>>> macros that were previously conditionally defined by a probe, so that
>>> code that was relying on HAVE_STRINGS_H instead of blind inclusion will
>>> still compile?
>>
>> How would one do to be portable to both "some versions of FreeBSD" and
>> MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs
>> HAVE_STRINGS_H to be defined and one needs to not have it defined.
>> Sounds evil to unconditionally define it under those circumstances. Or
>> have I misunderstood something?
> 
> Portable only to open toolchains, your choice of:
> 
> 1. Simplest:
> #include <strings.h>
> void foo() { strcasecmp(a, b); }
> 
> 2. Verbose:
> #include <string.h>
> #if HAVE_STRINGS_H
> # include <strings.h>
> #endif
> void foo() { strcasecmp(a, b); }
> 
> 
> Portable to MSVC toolchains:
> 
> 3. Verbose:
> #include <string.h>
> #if HAVE_STRINGS_H
> # include <strings.h>
> #endif
> void foo() { strcasecmp(a, b); }
> 
> The upshot is that if autoconf only cares about open toolchains (such as
> gcc on mingw when porting code to Windows), then it can unconditionally
> define HAVE_STRINGS_H (it must define this macro for back-compat to
> existing code that only includes <strings.h> inside that test).  But if
> autoconf still wants to cater to MSVC, then it must have a way to
> specify that the existence of strings.h must be probed.  This way does
> not have to be default; most packages need a LOT more work before they
> could compile under MSVC in the first place, so asking users that care
> about such setups to modify configure.ac to set some witness variable in
> order to force a probe instead of a blind define seems okay to me.
> 
> Personally, I don't care if any of my packages ever compile under MSVC -
> that's due in part to Microsoft's lack of regards towards standards and
> unwillingness to provide free tools (free license, not free price); in
> part due to the fact that gcc on mingw does just as well; and in part
> due to the fact that no one who does care has ever submitted a patch to
> any of my project mailing lists even trying to get that to work.
> Therefore, I would argue that future autoconf needs a way to minimize
> useless probing for strings.h, and it would be nicer (in my eyes) if
> this mode were the default; although I could also be persuaded that it
> is safer to have the no-probe mode only if I add a witness macro to my
> configure.ac.

If you leave a hook, then the macro is not defined unconditionally, which
was my gripe. A hook either way is fine, I will have a clean documented
way to make it portable then.

Also, to refresh your memory on MSVC-related patches to your projects,
you might want to reread e.g. this thread:

http://lists.gnu.org/archive/html/autoconf/2010-09/msg00002.html

Cheers,
Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]