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

[G M]

Hi

On Tue, Mar 4, 2014 at 7:56 AM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> 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
>
>
Obviously all these situations go on and I've advocated being feedback
driven on this.

I appreciate the callers point of view that in some orgs the machines are
locked down to one version even when that isn't desired.

But where that type of situation is not the case, don't let the feedback
drown out the fact that you can install VS and Express versions side by
side usually, so there is no "upgrade" of other things that needs to take
place until you want to.

I see even more reverts coming in now for C++11 elements that don't quite
work in VS2012. So we don't want to forget we are being impacted by where
we are, it's not just a case of being impacted by where we might go.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140304/2a61b11e/attachment.html>