[PATCH] setup.py: fix C extension compilation issue with OS X 10.9 and Xcode 5.1

[Kent Frazier]

Mads,

I'm not really familiar with clang flags, but if there is a tighter-scoped
one that accomplishes the same goal, I'd be inclined to agree that it would
be better to use that. To be honest, I copy-pasted the particular flag from
StackOverflow without really researching it. I made the change to the more
restrictive flag locally, and it appears to also resolve the compilation
issue. I also found this article that discusses the underlying issue with
the new version of clang:
https://langui.sh/2014/03/10/wunused-command-line-argument-hard-error-in-future-is-a-harsh-mistress/
In it, he uses ARCHFLAGS instead of CFLAGS. Both seem to work fine, but if
ARCHFLAGS would be more appropriate, perhaps I should make that change
also. I'm not really sure of the distinction between the two.

If I were to update the patch, what would be the most appropriate way to do
that? Should it be a fresh patch on top of the upstream tip, or a
modification of my current patch?

Kent


On Tue, Apr 15, 2014 at 6:18 PM, Mads Kiilerich <mads at kiilerich.com> wrote:

> On 04/15/2014 11:33 PM, Kent Frazier wrote:
>
>> # HG changeset patch
>> # User Kent Frazier <kentfrazier at gmail.com>
>> # Date 1397593632 14400
>> #      Tue Apr 15 16:27:12 2014 -0400
>> # Node ID 7e50af3ecb436f3dcd8f856e6d244d458675a62c
>> # Parent  76f68595ff8e5616a79dd79e962a97cc9ba58713
>> setup.py: fix C extension compilation issue with OS X 10.9 and Xcode 5.1
>>
>
>  +    # XCode 5.1 changes clang such that it now fails to compile if the
>> +    # -mno-fused-madd flag is passed, but the version of Python shipped
>> with
>> +    # OS X 10.9 Mavericks includes this flag. This causes problems in all
>> +    # C extension modules, and a bug has been filed upstream at
>> +    # http://bugs.python.org/issue21244. We also need to patch this here
>> +    # so Mercurial can continue to compile in the meantime.
>> +    if xcode51:
>> +        cflags = get_config_var('CFLAGS')
>> +        if re.search(r'-mno-fused-madd\b', cflags) is not None:
>> +            os.environ['CFLAGS'] = (
>> +                os.environ.get('CFLAGS', '') + ' -Qunused-arguments')
>>
>
> Nice to have a workaround so it works out of the box - thanks.
>
> The error message it avoids is:
>
> clang: error: unknown argument: '-mno-fused-madd' [-Wunused-command-line-
> argument-hard-error-in-future]
> clang: note: this will be a hard error (cannot be downgraded to a warning)
> in the future
>
> Do you have any thoughts on the merits of -Qunused-arguments compared to
> the apparently more narrow -Wno-error=unused-command-
> line-argument-hard-error-in-future ?
>
> /Mads
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140415/4d489a76/attachment.html>