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
> 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),Right. But this is again a historical (and LLVM-specific) artifact, because I doubt anyone uses such triplet outside to mean msvc compatibility.> but that'll probably be ok ultimately - internal function names are easy to > refactor if we decide to change the naming later.+1, but they should not confuse someone who reads / reviews the code :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote:>> 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), > Right. But this is again a historical (and LLVM-specific) artifact, > because I doubt anyone uses such triplet outside to mean msvc > compatibility. >Fair enough. Mostly most of the triples that exist aren't very useful for strict msvc compatibility since it wasn't a mode that gcc embraced :)>> but that'll probably be ok ultimately - internal function names are easy to >> refactor if we decide to change the naming later. > +1, but they should not confuse someone who reads / reviews the code :) >Yup, it was confusing in the first place which is why I'm commenting here :) -eric