On Sun, 25 Sep 2016, Brad House wrote:
> What other systems end up requiring a double-compile due to this?
Most *nix* systems can build applications either 32bit or 64bit. And while I
beleve most differences in 32 vs 64 bit builds can be found in the data size
checks (that your patch removes) I'm not SURE that is entirely true in all of
them. And when we have generated headers there's a small risk we'd introduce
any such difference in a future without realizing it. Removing the generated
headers completely would remove that (albeit minor) risk.
> 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.
Sure, that's one obstacle to overcome. But they are just three headers and I'm
quite sure we could figure out decent #ifdef checks for them and just do them
at the top of ares.h.
> 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.
Yes, this is the hardest part I think. If we were to remove ares_build.h, I
think we could just make ares_socklen_t be socklen_t by default and add
#ifdefs for the older legacy systems as we come across them and have
ares_socklen_t be int on those systems - and the detect those systems with
plain #ifdefs in ares.h.
> 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.
That would be one way, but I'd rather not go in that direction.
> 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.
Yes I believe it does. I think it is a step in the right direction so I intend
to merge it unless someone objects.
-- / daniel.haxx.seReceived on 2016-09-25