Re: Update config.guess to treat cygwin 1.7 as new system name

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Mon, Apr 27, 2009 at 06:01:57PM -0600, Eric Blake wrote:
>According to Christopher Faylor on 4/27/2009 10:02 AM:
>>>That would be fine with me.  Properly written scripts already use
>>>cygwin* as the case for detecting cygwin in general.
>>
>>I don't see any benefits to appending the cygwin version number to the
>>triplet.  That just makes extra typing.  So what if there is new
>>functionality?  That's what configure is supposed to determine.
>
>But there's some things that configure scripts cannot determine without
>guessing (namely, any runtime test in a cross-compilation environment).

We have an internal version number in Cygwin which is intended to
indicate new functionality.  The "1.7.x" or "1.5.x" isn't meant to be
used as a feature indicator.  It's just a general new release indicator.

>But there are a number of places that exist where the current
>cross-compilation guess is pessimistic because of cygwin 1.5 deficiencies,
>where distinguishing from cygwin 1.7 can only be done by uname and/or
>config.guess.
>
>Reread my original mail from February, when I first suggested this, and
>pointed to such an example:
>http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/printf.m4;h=4207ace;hb=f7beddb

Thanks for the pointer to the example.  It is funny how linux isn't
mentioned there when it seems like it would be a prime candidate for
this type of treatment.

>>What other systems emit version numbers after the OS name?  Certainly
>>config.guess for linux doesn't do that and it could have done that
>>given the improvements from 2.2 -> 2.4 -> 2.6.
>
>Solaris 6 through 11.  MacOS.  etc.  There's definitely precedence in
>config.guess for including OS version number in the config.guess
>output.

I can't tell if this actually made it into a definitive config.guess
source but I don't see how modifying config.guess to output
i686-pc-cygwin1.7 is going to help with cross compiling.

Since Cygwin 1.5 isn't expected to have a long shelf life I'd rather
that configure scripts just start changing to assume Cygwin 1.7 features
rather than complicating things with two potential Cygwin versions.  I
think that is a bad precedent to establish.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/