Joe Groff <arcata at gmail.com> writes:>> MSVC is not the system compiler. Certainly, it is not distributed with >> the system. Actually, MSVC was a secondary player on Windows for a long >> time, with several other C++ ABI-incompatible options available. > > > It isn't shipped with the system, but it's freely available as part of the > Windows SDK,That's a recent development which is irrelevant to this discussion. g++ and clang++ are freely available too.> and most binary library packages for Windows are shipped as > MSVC binaries.Irrelevant too, since those "MSVC binaries" (whatever that means) are usable by the other compilers.> *-*-win32 and *-*-mingw32 are different targets. Aside from C++, it's > useful to be able to use Clang as an MSVC compatible C99 compiler, since > MSVC itself only supports C89, and it's useful for LLVM to be usable by > other frontends that want MSVC compatibility. The win32 target can provide > that independent of the mingw target, which should of course remain > compatible with mingw's ABI.It only makes sense to talk about "MinGW's ABI" vs "MSVC ABI" in the context of C++, so your mention of C99 is also irrelevant.
Hi Oscar,>> MSVC is not the system compiler. Certainly, it is not distributed with > >> the system. Actually, MSVC was a secondary player on Windows for a long > >> time, with several other C++ ABI-incompatible options available. > > > > > > It isn't shipped with the system, but it's freely available as part of > the > > Windows SDK, > > That's a recent development which is irrelevant to this discussion. > g++ and clang++ are freely available too. > > > and most binary library packages for Windows are shipped as > > MSVC binaries. > > Irrelevant too, since those "MSVC binaries" (whatever that means) are > usable by the other compilers. > > > *-*-win32 and *-*-mingw32 are different targets. Aside from C++, it's > > useful to be able to use Clang as an MSVC compatible C99 compiler, since > > MSVC itself only supports C89, and it's useful for LLVM to be usable by > > other frontends that want MSVC compatibility. The win32 target can > provide > > that independent of the mingw target, which should of course remain > > compatible with mingw's ABI. > > It only makes sense to talk about "MinGW's ABI" vs "MSVC ABI" in the > context of C++, so your mention of C99 is also irrelevant. > >In my opinion none of these are irrelevant. Mingw and cygwin are separate ABIs that deal with some C compatibility (problems mentioned in this thread are important here too) and give you the ability to work with low level C libraries on windows, but if you want true compatibility with the full platform those ABIs are insufficient. If you think these are irrelevant points then you need to state why and should back it up with less dismissive language. Thanks! -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/bac73317/attachment.html>
Forgive me from intruding here, but ... whats wrong with isTargetWin32-MSVC-win32, isTargetWin32-mingw32-win32, isTargetWin32-borland-win32, isTargetWin32-cygwin-win32, etc. Judging by the responses, there seems to be a need for that. Which leaves the point of what should be 'the default', which could be borland for all i care... but perhaps not an as heated discussion ?
Eric Christopher <echristo at gmail.com> writes:> In my opinion none of these are irrelevant. Mingw and cygwin are separate > ABIs that deal with some C compatibility (problems mentioned in this thread > are important here too) and give you the ability to work with low level C > libraries on windows, but if you want true compatibility with the full > platform > those ABIs are insufficient.What do you mean by "the full platform"? Every propietary extension that MS came with along all these years? (From structured exceptions to whatever Windows RT requires?) MinGW is very well capable of using the Win32 API. There is partial or non-existent support for extensions such as COM, but those are not part of the "ABI", for sure.> If you think these are irrelevant points then you need to state why > and should back it up with less dismissive language.Sorry, but this goes the other way. If you need a lesson in history please start by investigating what "Borland" was, for instance. As already mentioned, for a long time MSVC was considered an inferior option and not required in any way for developing on Windows (not even for device drivers!) Then Borland and the other vendors were displaced by MSVC, but not because it was "the system compiler", nor even because it was technically better overall, severely lacking in C++ compliance, for instance. It gained market share because several reasons, among them because the other vendors had serious management problems and because MS marketers convinced the suits that for doing "serious" Windows development you need the tool made by MS itself. It is no surprise, but irritating nevertheless, that nowadays the fallacy is stablished as a truth. Sorry if I sound dismissive but it's quite irritating to see how authoritativeness is attributed to something that doesn't deserve it *to* *the* *detriment* *of* *our* *own* *project*.
John Smith <lbalbalba at gmail.com> writes:> Forgive me from intruding here, but ... > > whats wrong with isTargetWin32-MSVC-win32, > isTargetWin32-mingw32-win32, isTargetWin32-borland-win32, > isTargetWin32-cygwin-win32, etc. > > Judging by the responses, there seems to be a need for that. Which > leaves the point of what should be 'the default', which could be > borland for all i care... but perhaps not an as heated discussion ?The confussion here comes from the fact that on most other platforms there is one single platform and C++ ABI. The Itanium ABI on Linux/x86/amd_64 is one example. AFAIK all Linux C++ compilers aim to be C++ ABI-compatible with g++. On Windows, there is no such thing as a canonical C++ ABI. There is a platform ABI that is required for interfacing with the Win32 API, which is mostly an extension of some previous C ABI. Then, every vendor has its own C++ ABI (except Intel C++, which aims at being a drop-in replacement for MSVC++ on Windows and g++ on Linux.) The Windows platform ABI is supported by all C/C++ compilers out there (and at some point certain vendors shipped compilers supporting such ABI before MS itself did.) Then, there is a plethora of extensions which are required for interfacing with certain software packages and OS add-ons. Examples are structured exceptions, COM or .Net. Most of the time (not always) MS was the first vendor to ship a compiler supporting those extensions, but it was just another compiler in the field. Then the other vendors went bananas and MSVC achieved the predominance among the Windows developers. To the point: from the interest of Clang++ on Windows, it makes no sense to state that it supports the platform ABI. It must. Then there is the question about the C++ ABI, and here is where the diversity arises, because there are quite a few. It is obvous to me that the target name should mention the compiler that "defines" the C++ ABI Clang++ is configured for. For instance: mingw, msvc, borland or whatever. But there is no reason to mention win32 *alone* in the target name because there is no such C++ ABI. Saying that "win32" implicitly means MSVC++ could be an operative practice, but would belittle the other players, as if saying that MinGW is less of a Windows C++ compiler than MSVC. Considering that Clang++ already implements MinGW C++ ABI but is far from implementing Microsoft's C++ ABI, we certainly don't want that.