Finally I couldn't work on this today. But at least I'll answer this
thread anyway.

2007/12/20, Daniel Stenberg wrote:

> > [...]
>
> [...] if we provide a decent framework to add this it should be
> easy for people using these operating systems to fix this.

Certainly.

> > [...]
>
> This is in fact already done. There's a generic script in the
> root makefile.am file that scans all subdirs for .dist files to
> rename, for release. That's how we make the
> include/curl/curlver.h file as well etc.

Good.

> Ah, another detail to fix is that include/curl/Makefile.am has
> a 'CLEANFILES = *dist' line, which then rather should explicitly
> mention the ones to remove since the types.h.dist shouldn't
> really be removed on 'make clean'

Even further, I think that there would be no need to delete anything
from include/curl/ on make clean. All three, types.h.in types.h.dist
and types.h should be kept around. So the question here is. Is it
better an empty CLEANFILES or just remove the line.

Probably curl/include/README would also need some editing.

> >> Is this method working fine if we try to install the headers when we build
> >> outside the source dir on a *nix box? I guess I need to check it out...
> >
> > Don't know. I'll try this later today.
>
> I've tried it now and it seems to work fine.

Good

> >>> Should we go this route ?
> >>
> >> Do we have any other reasonable approach to select from? To me
> >> this seems like a doable way at least.
> >
> > Even if we do this. socklen_t in the interface will hunt us back again for
> > some platform not capable of running the configure script. At least we
> > reduce the possibility.
>
> Yeah. :-/
>
> The question is perhaps what the possible punishment will be on
> us if we try to revert the socklen_t introduction. On what platforms
> will changing socklen_t over to for example 'unsigned int' make a
> difference?

I think, that besides 'formally' breaking both ABI and API relative to
libcurl 7.17.1 as you have already stated, the impact would be quite
minimal as long as we don't try to replace all occurrences of
socklen_t internally in libcurl and just restrict the change to the
curl_sockaddr struct in the public interface.

The reason for this is that at this moment it is only used for the
open/create socket callback function which can be called instead of
socket() when creating a connection. So, at most, only apps which are
using such a callback could be affected, and even in this case in a
very minor way. In our code in connect.c at most a couple of type cast
changes.

On the other hand, we have the future ;-) Obviously, if we provide now
the framework to expose/require this socklen_t in the public
interface, if the day arrives that there is actually a better reason
to expose/require it, the work would already be done. Not to mention
that it would be the way to provide configuration time definitions for
the external API.

So I guess, that in the long run, it is better if we finally do this
instead of just changing socklen_t over to for example 'unsigned int'
in the public interface.

-- 
-=[Yang]=-