Re: git interix support

[Daniel Barkalow <barkalow@iabervon.org>]

On Tue, 9 Mar 2010, Markus Duft wrote:

> Hey.
> 
> i have "ported" git to interix (haha, wasn't so much of a problem after
> all ;)). i have a small patch (attached). i know that it sure doesn't
> have production quality yet, but i try gathering ideas/input here.
> 
> additionally to the patch i'm setting:
> 
> 147     if [[ ${CHOST} == *-interix* ]] ; then
> 148         myopts="${myopts} NO_IPV6=YesPlease"
> 149         myopts="${myopts} NO_MEMMEM=YesPlease"
> 150         myopts="${myopts} NO_MKDTEMP=YesPlease"
> 151         myopts="${myopts} NO_STRTOUMAX=YesPlease"
> 152         myopts="${myopts} NO_STRTOULL=YesPlease"
> 153         myopts="${myopts} NO_INET_NTOP=YesPlease"
> 154         myopts="${myopts} NO_INET_PTON=YesPlease"
> 155         myopts="${myopts} NO_NSEC=YesPlease"
> 156         myopts="${myopts} NO_MKSTEMPS=YesPlease"
> 157     fi
> 
> interix lacks propper poll() support (poll is there but broken), so some
> of the things in git have to be disabled for now, or replaced by a
> select() code (but that'd take precious time of mine to implement (argh)).
> 
> any comments on the patch? any chance to get stuff upstream?

If you've got programs that don't work at all without some library 
function that you don't have, it's better to not build them at all (by not 
having them in the make targets) than build binaries that refuse to run. 
Doing it that way means you don't need to get the rest of the file to 
compile, and makes it more clear before runtime what functionality will be 
missing.

Also, if you make a NO_POLL and use that, someone else might make a 
compat_poll(). Or maybe not, but a workaround certainly won't get done if 
you just use __INTERIX.

	-Daniel
*This .sig left intentionally blank*