Host compiler requirements: Dropping VS 2008, using C++11?

Hi all,

A few days ago, there was a report of LLVM not compiling on VS 2008,
because of asymmetric std::lower_bound comparators not supported
there.

As noted by a few people, maybe it's time to drop VS 2008
compatibility and move the requirements to VS 2010?

While there, what about going further and starting using C++11? Now
seems as good a time as ever; my takeaway from that few months old
discussion was that once 3.3 is released, it would be reasonable to
start using features supported by VS2010 / gcc-4.4 / clang-3.1. That
would be now, are there any objections left?

-- Ahmed

> There is some historical precedence for fixing the problem with VS
> lower_bound by changing the LLVM source - when I first got LLVM to compile
> with Visual Studio, patches for unsymmetric operator < were accepted into
> the LLVM repo, and I believe it's been done several times after that as
> well.

In the C++11 discussion back in January
(http://llvm.1065342.n5.nabble.com/Using-C-11-language-features-in-LLVM-itself-td53319.html)
there seemed to be some kind of consensus for 2010 being a reasonable
minimum. Perhaps this is a good time to break compatibility
officially.

Actually, whatever did happen to using C++11? No-one mentioned
anything about it after that thread.

Valid points, raised in the commit thread. Changed the subject to get
people's attention!

I'm in favor of dropping VS 2008 support (in fact, I thought we had
already talked about doing that, but perhaps I am remembering
incorrectly).

I think C++11 support should be a separate discussion than dropping VS
2008 support because it's likely to be a bit more in-depth, but I'm in
favor of it.

~Aaron

I'm also in favor of dropping VS 2008 if nobody has a strong need for it,
but C++11 is a different discussion.

Does anyone know if we have any contributors that rely on VS 2008?

- Michael Spencer

I'm in favor of dropping VS 2008 support (in fact, I thought we had
already talked about doing that, but perhaps I am remembering
incorrectly).

+1 -- we're good with dropping VS 2008, especially if we document it
clearly in the release notes.

I think C++11 support should be a separate discussion than dropping VS

2008 support because it's likely to be a bit more in-depth, but I'm in
favor of it.

+1

I (arduously) updated the docs, so VS 2008 support is gone now.

I’m still curious about C++11 though!

-- Ahmed

-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).

ok but clang/llvm need to move forward too. VC 2008 is 5 years old now.
MSVC express edition is free and can be used to develop LLVM/CLANG so there
is no excuse ($$$ or license) to not update to a more recent edition.

Personally I think we should support the current and the last previous
version of MSVC.

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.

I've got one project still using Visual Studio 2005. It has to be used
because the resulting library was certified using a specific Microsoft
runtime library. We can't change the platform because it would require
a re-certification (the certification costs around 100K USD).

As crazy as it sounds, we can install the software on a new version of
Windows (Windows 7 or Windows 8), and the certification still applies.

Jeff

+1. I completely agree.

-Chris