> -----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 <jrnieder@xxxxxxxxx> writes: > > > >> Mark Levedahl wrote: > >> > >>> > However, > >>> 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 > > adbc0b6b6e57c11ca49779d01f549260a920a97d > > 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 Ug! > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html