[cfe-dev] Supporting building clang/llvm with VS2012. Why that one?

[Robinson, Paul]

> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at 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?
> 
> On Mon, Mar 3, 2014 at 5:44 AM, Dallman, John <john.dallman at siemens.com>
> wrote:
> > 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