RE: Version 1.8.1 does not compile on Cygwin 1.7.14

> -----Original Message-----
> From: git-owner@vger.kernel.org 
> [mailto:git-owner@vger.kernel.org] 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@vger.kernel.org; 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@gmail.com> 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.

> 
> 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.

> 
> 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.
> +#