[cfe-dev] Host compiler requirements: Dropping VS 2008, using C++11?

[Chandler Carruth]

On Tue, Jul 23, 2013 at 7:17 PM, Wang Qi <wqking at outlook.com> wrote:

> -1.
>
> I believe there are still a lot of people using VC 2008, though I can't
> give the data.
> VC 2008 (even the express version) is enough for a lot of development,
> such like game development.
>
> Most likely I myself will continue using VC 2008 for at least two or more
> years.
>
> Unlike other C++ compiler, **Clang is not only a compiler, but also a
> great open source library**. An open source library should better keep
> lowest compiler/platform requirements, when possible.
>
> Also, seems Microsoft's development tools have quite long life and can
> spread into many years. For example, VC6 is not complete dead up to
> today... (some time ago I read on Reddit comment that somebody still needs
> to maintain a code base written with VC6).
>

Unless someone within the community steps forward with a powerful argument
to continue to support VC 2008, I'm going to make the call: we don't
support it.

Why? I don't actually disagree with your points, but I think there are
overriding concerns:

1) The pragmatic fact is that we simply don't have enough contributors and
active (within the community) users that use, exercise, report bugs, and
provide patches to support VC2008 to credibly say we support it. The fact
is that we already don't, and we won't going forward regardless of what
folks say on this email thread.

2) #1 isn't a problem that it is worth it to the community to solve. That
is, I would rather have the developers and members of the community working
to better support more modern Windows platforms rather than this old one.
So I think it is actively in our best interest to not invest in changing #1.

3) LLVM (and its subprojects) have a long history of beneficially tracking
and leveraging modern aspects of C++. We want to do more of this faster,
not less of it slower, because it significantly improves the cleanliness,
maintainability, simplicity, and performance of our libraries. To this end,
it is directly to the benefit of the project to stay as close as possible
to the latest versions of the various toolchain vendors.

4) Users of LLVM that are necessarily dealing with an unchanging toolchain
and environment always have the option of freezing their version of LLVM
along with that environment, or working assiduously to build a sufficiently
strong role within the community to both provide the necessary testing and
fixes for the environment (#1 above) and overcome the burden it places on
the rest of the project (#3).

At this point, I suspect we should put the subject to rest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130723/ae5664b8/attachment.html>