[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
From: |
Charles Wilson |
Subject: |
Re: [patch #6448] [MSVC 7/7] Add MSVC Support |
Date: |
Fri, 29 Aug 2008 14:15:48 -0400 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 |
Peter Rosin wrote:
> Charles Wilson skrev:
>> I also think that -winnt is too broad; and I'd really hate to see the
>> massive uglification of the libtool code -- and thousands of
>> configure.ac's out there -- that would ensue if -mingw* were
>> /officially/ overloaded to also represent the msvc-toolchain case.
>
> Thanks a bunch for that. Where specifically is this "massive
> uglification" in the pr-msvc-support branch?
Sorry for the delay -- I've been snowed under this week. What I meant
was that there will soon be a proliferation of instances in ltmain where
case $host in
*-*-mingw* )
stuff will have to be special-cased with 'case $CC in' sub-clauses. (I
know, I know -- policy is that all that stuff is handled in *.m4, and
ltmain is "generic". But in practice, it isn't true).
However, looking more closely, there's no difference in that outcome
than in the way we currently handle different compilers on, say,
solaris. There are special cases for 'case $CC in *gcc*)' already.
And, in master, we already have some (bitrotted) special casing for
$host mingw in the form of 'when $CC is not gcc, assume msvc and do this
stuff instead...'
For client packages, I know that /I/ have been guilty of assuming
'mingw' implies 'gcc', and I've seen many others that do, as well. But
again, that's no different that "portable" packages that assume
$host==solaris implies gcc. They break when you try to use Sun's
compiler -- and that is a /bug/ in the client package. It's not the
fault of libtool or an indication that the $host triple is incorrect.
Finally, there's one additional benefit to using *-*-mingw* to mean "the
windows runtime platform operating within the Win32/Win64 subsystem" --
regardless of the compiler being used (as distinct from the Posix
subsystem that interix uses, or the cygwin runtime operating in the
Win32 subsystem):
It makes RMS happy. (Look ma, no "win")
Ok, ok, maybe that was uncalled for. <g>
But still, consider me convinced.
--
Chuck
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, (continued)
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Charles Wilson, 2008/08/25
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/25
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Charles Wilson, 2008/08/25
- RE: [patch #6448] [MSVC 7/7] Add MSVC Support, Duft Markus, 2008/08/26
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/26
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/28
- Message not available
- RE: [patch #6448] [MSVC 7/7] Add MSVC Support, Duft Markus, 2008/08/29
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/29
- Message not available
- RE: [patch #6448] [MSVC 7/7] Add MSVC Support, Duft Markus, 2008/08/29
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/29
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support,
Charles Wilson <=
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/26
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/25
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/18
- Archiver handling (was Re: [patch #6448] [MSVC 7/7] Add MSVC Support), Peter Rosin, 2008/08/18
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/30
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/08
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Ralf Wildenhues, 2008/08/09
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/09
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Peter Rosin, 2008/08/09
- Re: [patch #6448] [MSVC 7/7] Add MSVC Support, Ralf Wildenhues, 2008/08/11