RE: Version 1.8.1 does not compile on Cygwin 1.7.14

["Pyeron, Jason J CTR (US)" <jason.j.pyeron.ctr@mail.mil>]

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

> -----Original Message-----
> From: Junio C Hamano
> Sent: Monday, January 07, 2013 2:29 AM
> 
> Jason Pyeron writes:
> 
> [administrivia: please never cull CC list when you respond to a
> message on this list without a good reason]

Apologies, I just have 4 copies of every message and was trying to save other that pain.

> 
> >> circumvent the Cygwin API (and by extension, Cygwin project goals).
> >>
> >> So, perhaps a better path forward is to disable / remove the
> >> above code by default. (Those wanting a native Win32 git
> >> should just use the native
> >> Win32 git).
> >
> > Or a make option...
> 
> It already is a runtime option, isn't it?
> 
> I do not have much stake in this personally, but IIRC, the (l)stat
> workaround was back then found to make Cygwin version from "unusably
> slow" to "slow but torelable", as our POSIX-y codebase assumes that
> lstat is fairly efficient, which Cygwin cannot satisify because it

Is there already a set of test cases I can run to validate that this is still true?

> has call many win32 calls to collect bits that we do not even look
> at, in order to give faithful emulation.  It does place extra
> maintenance burden (e.g. conditional compilation depending on the
> header file the particular version of Cygwin installation the user
> has at hand) on us, but as long as it works, the ugly hack is fairly

There seems to be only 2 valid use cases here, with regards to cygwin.

1. Do it the normal posix way, and don’t hack it up.
2. For speed reasons, merge in native windows/non-posix functions.

I would not care about the user's cygwin version because the cygwin supporters won't either. In both cases assume the latest cygwin libraries. If there is a specific user with a use case for an older version of cygwin libraries then we can cross that bridge when (if) we arrive at it.

> isolated and I do not see a reason to unconditionally rip it out,
> especially if the reasoning behind such move is on "All programs
> that run in Cygwin environment has to be POSIX only and must not use
> Win32 API directly, even in a controlled way."

I presently do not care if it stays or goes. But if someone were to bring this to the cygwin mailing list it would be a headache to deal with the "hacked" way. They would likely be more receptive to increasing the efficiency of the lstat than other approaches.

> 
> It is a completely different matter if the direct win32 calls we
> make, bypassing (l)stat emulation, somehow change the internal state
> of win32 resources Cygwin controls and violates the invariants
> Cygwin API implemenation expects, breaking later calls to it.  I
> do not know that is the case here, but I doubt it.

I agree, it is not going to break anything here. Those libraries are just a way of presenting the Windows API without using Microsoft files and making it easier to wrap the POSIX apis to it. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]