Supporting building clang/llvm with VS2012. Why that one?

Hi,

Sorry if this is a silly question, please don’t bite my head off, but:

If I understand the situation correctly, clang/llvm aims to be buildable by VS2012.

What’s the rationale for this?

VS2012 is a pretty recent build, perhaps too recent to represent an amazingly large number of users versus earlier versions of Visual Studio.

Given that, why not aim to be compatible with VCExpress 2013 instead of VS2012 and track the latest of that as soon as it’s released. A new version is coming soon I understand.

I say this because it’s free and both VS2012 and VCExpress can be installed side by side. So why not?

By doing that you shouldn’t be losing any significant number of users (if any) compared to VS2012, and you gain by being able to use the very latest C++11 features that MSVC supports as soon as it’s available.

Anyone who wants to use clang just has install the latest VCExpress and there doesn’t appear to be a good reason not to given it’s free and the versions work side by side?

Just a thought. I’d like to know what people think. The outcome of the answer doesn’t make any difference to me, but it just seemed as sensible to track the latest version than a version that might not have the largest user base anyway.

I’m seeing the odd reverts in llvm/clang because some things aren’t compatible with VS2012, but they might be compatible with VS2013 and even more so with the new VS2013 update about to come out. That’s the point of this.

Sorry if I’ve missed a good reason why things are the way they are, like if clang doesn’t build with VCExpress or something. I don’t use it to build clang, I use mingw, but I was curious so thought I’d ask. Hope it’s a useful question.

Thanks

VisualStudio 2012 has been out for well over a year, whereas 2013 has been
out for only a few months. There was a reasonable amount of effort required
just to get everyone migrated from 2010 to 2012, I think it would be quite
hard to try to get everyone onto 2013. At the time I floated the suggestion
of 2012 as the minimum version, 2013 still miscompiled LLVM pretty badly
IIRC, but that was one of the early preview versions.

However, I'm perfectly happy for the actual Windows users of LLVM and Clang
to make this call. I personally think that given the challenges with the
C++11 support in older versions of VisualStudio in general, it makes sense
to be significantly more aggressive with the host toolchain version minimum
there. But we have to listen to the users on the platform. If there are
folks using VS2012 that would be unable to move to 2013, I think supporting
them is likely worth the cost at least for a while.

FWIW, I switched compiler to VC 2013 few weeks after Aaron worked around the miscompile.

However, someone working within larger organization don’t always have this flexibility.

Yaron

Hi Yaron

FWIW, I switched compiler to VC 2013 few weeks after Aaron worked around the miscompile.

However, someone working within larger organization don’t always have this flexibility.

Yaron

I agree the idea needs to be driven by the feedback

But in principle, I would perhaps naively think that “most” people should have the option to install most versions of VS20XX and/or VS Express 20XX where they are known to work side by side, and especially as one is free.

Any organisation can make any rule it likes, but it’s not clear to me, subject to disk space, what reasonable rule would want to prevent someone installing a full Visual Studio and an Express VS version together, or hold both of them back at some old version and allow no other versions if they work fine side by side.

If some organisation wanted to do that, it’d seem like that company would be even less likely to experiment with clang at all.

The most common reason I can imagine why people wouldn’t install a really recent version of either VS or VSExpress is because they don’t want to, probably for no other reason other than they can’t be bothered, lack of disk space, or are worried it’ll mess their system up. That’s a concern, but that’s what backups are for and I’m not sure those reasons would be good enough reason to hold back progress.

If cfe-dev is staying on top of the situation and testing these things basically work before recommending them to everyone, the risks would diminish too one would hope.

There might be realistic angles I haven’t thought of and that’s why I asked the question but I’m keen to see what obstacles, or not, people come up with, and where they stack up with regards to being tangible or theoretical and in what numbers.

G M wrote:

Any organisation can make any rule it likes, but it's not clear to me, subject to disk
space, what reasonable rule would want to prevent someone installing a full Visual Studio
and an Express VS version together, or hold both of them back at some old version and
allow no other versions if they work fine side by side.

If some organisation wanted to do that, it'd seem like that company would be even less
likely to experiment with clang at all.

You are radically over-estimating the internal consistency of large organisations. Some of
them want to have standard configurations for machines, because that sounds good to people
who make policy, and means it's easy to replace machines that go bad. They are very capable
of failing to realise that would prevent use of new software, because the people who make
the policies either don't understand software development - thinking in terms of office
automation instead - or just fail to join the dots. Fortunately, most of them don't have
effective enforcement for their policies, so they can be worked around.

Remember, Dilbert is funny because it isn't exaggerated very much.

While all of that is certainly true to some degree - one doesn't have
to be that uninformed to end up in a situation where they're using an
old toolchain. Every compiler upgrade comes with some cost of bug
hunting and source changes to accommodate it - when and how that cost
is justified varies.

So, yes, there are reasonable (and unreasonable but still real)
reasons that people might be running an old toolchain for large
projects.

The (possibly incorrect) assumption in the original post here is that
it was just a matter of what was installed to work on LLVM itself, but
this doesn't account for the fact that many people use LLVM (and Clang
moreso) as a library built into larger projects - the cost involved in
upgrading a compiler means upgrading the whole project to work with
the newer compiler. (and all other engineers working on that project
need to pay that cost - not just those working on the LLVM portions)

In any case, as Chandler said - those working on Windows can best
assess their versioning needs, but it's healthy to reach out and ask
sometimes just to check if we're not stuck in a rut where everyone
assumes everyone else is the limiting factor keeping us back on older
tools.

- David

From: cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu]
On Behalf Of David Blaikie
Sent: Monday, March 03, 2014 8:11 AM
To: Dallman, John
Cc: cfe-dev
Subject: Re: [cfe-dev] Supporting building clang/llvm with VS2012. Why
that one?

> G M wrote:
>
>> Any organisation can make any rule it likes, but it's not clear to
me, subject to disk
>> space, what reasonable rule would want to prevent someone installing
a full Visual Studio
>> and an Express VS version together, or hold both of them back at some
old version and
>> allow no other versions if they work fine side by side.

Having worked for a few large organizations over the past few decades,
delivering enterprise software to large customers, the main reason for
sticking with a specific version of your build tools is:
Stability in the delivered product.
Upgrading build tools requires at least as much QA as a normal product
delivery cycle, and for zero new functionality (other than, we hope,
better performance due to improved code generation by the new build
tools). New build tools have to earn their trust.

This is a reasonable rule for that kind of organization. Not all
organizations are that kind, but my current employer is absolutely
in the "valuing stability" camp, even though I wouldn't classify
us as delivering enterprise software.

The (possibly incorrect) assumption in the original post here is that
it was just a matter of what was installed to work on LLVM itself, but
this doesn't account for the fact that many people use LLVM (and Clang
moreso) as a library built into larger projects - the cost involved in
upgrading a compiler means upgrading the whole project to work with
the newer compiler. (and all other engineers working on that project
need to pay that cost - not just those working on the LLVM portions)

Heh--I once had to stick with an old set of build tools because we
used a no-longer-supported third-party library for which we could not
get a source license. It took management a looong time to agree to
replace something that was "working just fine" because replacing it
represented a large investment and a large risk.

Even apart from unfortunate circumstances like that, it's not easy.
Contemplate, for a moment, the degree of coordination it took to get
all of the LLVM buildbots (a) upgraded and (b) working, with the new
minimum compiler versions. You don't want to do that too often.

In any case, as Chandler said - those working on Windows can best
assess their versioning needs, but it's healthy to reach out and ask
sometimes just to check if we're not stuck in a rut where everyone
assumes everyone else is the limiting factor keeping us back on older
tools.

- David

We're a little behind the curve but we're upgrading from 2010 to 2012.
Nobody here is opposed to it, but the logistics of getting it all done
is non-trivial and needs to be scheduled in between other priorities.

--paulr

Hi