On Thu, Mar 28, 2013 at 12:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> 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. > >I don't care overly much about COM, but I do care about the C++ abi and using C++ libraries on the system and interacting with those libraries via clang.> > 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 historyplease start by investigating what "Borland" was, for instance. As>I'm quite familiar with Borland, thank you.> 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. >Honestly it doesn't much matter about history in this case. I understand the frustration coming from your perspective, but these days running binaries on windows involves interoperating with things compiled by MSVC. To have a toolchain that works with as many libraries on the system as possible requires interoperability with the tools used to compile those libraries. In this case it is MSVC and their ABI.> 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*. >How can having an MSVC compatible compiler be to the detriment of clang and llvm? No one is trying to break mingw here, merely add support for something else. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/1cc86c78/attachment.html>
On Thu, Mar 28, 2013 at 1:15 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote:>> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means "msvc-compabile" > - isTargetWin32() which means "everything on windows", so Windows + > Mingw + Cygwin > - isTargetWin64() is is basically 64-bit version of isTargetWin32(), > but strictly speaking is slightly different > > This naming while being the historical artifact is extremely > confusing. For me it seems the best solution will be something like > this: > - isTargetMingw() - with obvious meaning > - isTargetMSVC() - with obvious meaning > - isTargetWindows() which will include all the flavours (so only OS > will matter here) > - isTargetWindows() can be combined with existing 32/64 bit checks > > This way we'll end with something being non-ambiguos. >Sounds fine to me. I just wanted some convenient and consistent naming. I think it conflicts a bit with the triples (-win32 currently means msvc I think), but that'll probably be ok ultimately - internal function names are easy to refactor if we decide to change the naming later. -eric
Anton Korobeynikov <asl at math.spbu.ru> writes:>> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for somethingI'm all for a Clang++ compatible with MSVC++. I'll love to replace MSVC++ with Clang++ as my Windows compiler. That's not what arguing about. I'm saying that anything that could suggest that MSVC++ is more desirable than the other compilers is not only unfair, but would go against Clang's interest because Clang will sooner get full MinGW drop-in capability than MSVC++ drop-in capability. So any detriment to the technical merits of MinGW would affect Clang too for a long time. Naming APIs on a way that privileges MSVC++ hurts MinGW and Clang.> - isTargetMingw() - with obvious meaning > - isTargetMSVC() - with obvious meaning > - isTargetWindows() which will include all the flavours (so only OS > will matter here) > - isTargetWindows() can be combined with existing 32/64 bit checks > > This way we'll end with something being non-ambiguos.+1
2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>:>> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means "msvc-compabile" > - isTargetWin32() which means "everything on windows", so Windows + > Mingw + CygwinMinor correction: currently isTargetWin32 means 32-bits (not "everything"), Windows + Mingw, not Cygwin. So this is actually even more confusing...> - isTargetWin64() is is basically 64-bit version of isTargetWin32(), > but strictly speaking is slightly different > > This naming while being the historical artifact is extremely > confusing. For me it seems the best solution will be something like > this: > - isTargetMingw() - with obvious meaning > - isTargetMSVC() - with obvious meaning > - isTargetWindows() which will include all the flavours (so only OS > will matter here) > - isTargetWindows() can be combined with existing 32/64 bit checks > This way we'll end with something being non-ambiguos.I think this is a much better naming than we have now, I'll prepare a patch for that. Should we change the ***-pc-win32 triple to ***-pc-msvc ?> -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev