Update config.guess to treat cygwin 1.7 as new system name
Christopher Faylor
cgf-use-the-mailinglist-please@cygwin.com
Tue Apr 28 00:47:00 GMT 2009
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/
More information about the Cygwin
mailing list