> -----Original Message-----
> From: Mark Levedahl
> Sent: Sunday, January 06, 2013 17:17
> On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> > Jonathan Nieder <jrnie...@gmail.com> writes:
> >> Mark Levedahl wrote:
> >>> the newer win32api is provided only for the current
> cygwin release
> >>> series, which can be reliably identified by having dll version
> >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from
> >>> redhat, 1.5.x open source) still have the older api as no
> updates are being made for the legacy version(s).
> >> Ah. That makes sense, thanks.
> >> (For the future, if we wanted to diagnose an out-of-date
> win32api and
> >> print a helpful message, I guess cygcheck would be the command to
> >> use.)
> > Hmph, so we might see somebody who cares about Cygwin to
> come up with
> > a solution based on cygcheck (not on uname) to update this part,
> > perhaps on top of Peff's "split default settings based on
> uname into
> > separate file" patch?
> > If I understood what Mark and Torsten wrote correctly, you
> will have
> > the new win32api if you install 1.7.17 (or newer) from
> scratch, but if
> > you are on older 1.7.x then you can update the win32api part as a
> > package update (as opposed to the whole-system upgrade). A
> test based
> > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> > installation has a newer win32api because the user updated
> it from the
> > package (hence the user should not define CYGWIN_V15_WIN32API).
> > Am I on the same page as you guys, or am I still behind?
> > In the meantime, perhaps we would need something like this?
> It's perhaps worth noting how we got into this mess. The
> problems have their root in
> Cygwin's entire goal is a completely POSIX compliant
> environment running under Windows. The above commit
> circumvents some of Cygwin's API regarding stat/fstat to make
> things perhaps a bit faster, and definitely not POSIX
> compliant (The commit message is wrong, the commit definitely
> breaks POSIX compliance). That code is also what will not
> compile on different w32api versions. It is curious: the
> Cygwin mailing list has been absolutely silent since the
> w32api change was introduced last summer, this is the only
> piece of code I am aware of that was broken by the new
> headers, and of course the purpose of this code is to
Um, going out on a limb here, but those headers are used internally as "cygwin"
apps are most likely to now know about those headers.
> 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...
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
This message is copyright PD Inc, subject to license 20080407P00.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html