Subject: Re: Release coming up!

Re: Release coming up!

From: Brad House via c-ares <c-ares_at_cool.haxx.se>
Date: Sun, 25 Sep 2016 16:16:55 -0400

On 9/25/16 12:43 PM, Daniel Stenberg wrote:
> On Sun, 25 Sep 2016, Brad House wrote:
>
>> I should also-recap the GOAL of the patch. The goal is for MacOSX and iOS to allow multi-arch building.
>
> Right, and I'm looking beyond MacOSX and I want to completely remove the need to double compile for *all* systems. And
> the safest way to really make sure there's no such need left, is to remove the generated header completely.
>

What other systems end up requiring a double-compile due to this? Can you give an example
of what is left that would required to be changed to prevent this? I'm personally not aware
of any other system that operates like MacOSX in this way, so I don't know what caveats
such systems might have and how it differs to be able to properly evaluate what you are saying.

Though I generally agree needing to build a header to be distributed that is in some way specific to
the OS isn't optimal ... however, in this case, due to the API of c-ares, I see it being needed
for 2 reasons.

1) Including the cares.h file requires *other* headers be included before it or it will result
    in build failures, and the headers that need to be included are system-dependent (they are
    not the same across all platforms). It appears ares_build.h handles this aspect.
2) ares_socklen_t is part of the public api, and it appears to mostly map to socklen_t on
    systems that have it, or 'int' for systems that don't. It does seem dependent on this
    to ensure the size is within range.

Essentially, in order to solve these 2 items (maybe there's more?), I believe you'd need to
change the public API of c-ares to NOT use any system-defined types what-so-ever. Considering
the maturity of c-ares, and the overall lack of need for huge new features, I'm not sure such
breakage could be justified.

I guess the goal of my patch was more narrow than you had hoped for, but I think it is still
a step in the right direction as it does both clean up code that doesn't follow best practices,
removes dead wood, and improves platform support for MacOSX and iOS.

-Brad
Received on 2016-09-25