[lldb-dev] [cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
wolfeinstein at gmail.com
Sat Aug 23 13:55:05 PDT 2014
MSVC survives because there's no effective competition- it's like
communications providers in the United States or political parties in
China. The alternatives like GCC have no decent development environments
for them, and Clang has the bonus of not being mature w.r.t. things like
Standard libraries. The reality is, there's nowhere to go *but* MSVC. This
stuff is the major reason why I'd positively love clang-cl. As soon as that
is done, then support for cl can probably be entirely dropped and the state
of the available compilers will be drastically improved.
Microsoft *is* issuing more and more out-of-band bugfix updates. But the
current state for VS2013 is still that most bugfixes will hit in VS "14"
(currently projected for 2015).
On 23 August 2014 21:24, Renato Golin <renato.golin at linaro.org> wrote:
> On 22 August 2014 20:18, Óscar Fuentes <ofv at wanadoo.es> wrote:
> > I second this. My experience with VS is that new features are usually
> > broken if you go beyond the simple cases. And the roadmaps have little
> > credibility, based on a continuous flow of disappointments since...
> > forever.
> Is there any interest from Microsoft to actually fix those problems,
> or is that their policy that what's there is there? The latter seems
> to be their policy on other products, and for what I know, VS too. I
> ask that because holding on partial and broken support that will never
> be fixed or completed is kind of backwards.
> I'm not a Windows guy, but I wonder why so many people use MSVC if the
> support is so patchy and hopeless as most people seem to imply. Also,
> compiling Clang with MSVC and making Clang MSVC compatible are two
> completely different things. A commercial toolchain based on MSVC
> compatibility doesn't necessarily need to be compiled with MSVC
> Or maybe the Windows environment is so alien that I'm basing my points
> on completely unreasonable assumptions...
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev