> -----Original Message----- > From: git-owner@xxxxxxxxxxxxxxx > [mailto:git-owner@xxxxxxxxxxxxxxx] On Behalf Of Mark Levedahl > Sent: Sunday, January 06, 2013 16:10 > To: Junio C Hamano > Cc: Jonathan Nieder; Torsten Bögershausen; Stephen & Linda > Smith; Jason Pyeron; git@xxxxxxxxxxxxxxx; Eric Blake > Subject: Re: Version 1.8.1 does not compile on Cygwin 1.7.14 > > 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? > > > > > > diff --git a/Makefile b/Makefile > > index 8e225ca..b45b06d 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -281,6 +281,9 @@ all:: > > # > > # Define NO_REGEX if you have no or inferior regex > support in your C library. > > # > > +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api > dll older > > +than # 1.7.x (this typically is true on Cygwin older than 1.7.17) # > > # Define HAVE_DEV_TTY if your system can open /dev/tty to > interact with the > > # user. > > # > > > Looking at a current setup.ini, the obsolete win32 api is a > single package "w32api" with last version 3.17-2, and is now > replaced by the new win32 api is in two packages, > "w32api-headers" + "w32api-runtime", both at version > 3.0b_svn5496-1. If setup.exe updated an older installation of > w32api, the old package is not deleted, but replaced by a > special "empty" package with (as of today) version 9999-1. > Note that all of this could change at any time. Also, note > that the new w32api packages have version numbers that are > lower than the older obsoleted version. I would not rely on that information as it is not designed to convey the information the git build needs. > > Running "cygcheck -c w32api w32api-headers w32api-runtime" on > one machine gives > > Cygwin Package Information > Package Version Status > w32api 9999-1 OK > w32api-headers 3.0b_svn5496-1 OK > w32api-runtime 3.0b_svn5496-1 OK > > So now, what do folks propose checking for? > a) w32api is installed? Nope - the package is not "removed", > it was updated to a special empty version to delete its > former contents, but a new fresh installation won't have this. > b) w32api-headers is installed? Nope - what happens on the > next repackaging? > c) w32api version is 9999-1? Maybe, but that number could change. > etc. This is what is typically done in a configure script by test compiling. > > There is no documented, reliable, future-proof, method of > determining the installed w32api version on Cygwin. There are > many things that can be done that will work frequently, > except when they won't. I really think the only sane thing is > to follow the guidance of the Cygwin > developers: the only supported configuration is that which > the current setup.exe produces, and in the case of problems, > if the installation is not up to date then updating is the > first required action. > > So, in the makefile, you might add: > > +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x > but are not > +# using the current w32api packages. But, the recommended > approach is > +to # update your installation if compilation errors occur. > +# -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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