[LLVMdev] diffs for vc7.1

Reid Spencer reid at x10sys.com
Wed Sep 15 10:18:01 PDT 2004


On Wed, 2004-09-15 at 08:58, Jeff Cohen wrote:
> On Wed, 15 Sep 2004 07:39:23 -0700
> Reid Spencer <reid at x10sys.com> wrote:
> 
> > Yes, in fact I'd be daring enough to suggest that it be the standard.
> > We'll have fewer compilation problems with VC++ 2005 because it is
> > (supposedly) more standards compliant than previous versions. Please use
> > this download:
> 
> While this may be true, it's not a realistic request.  Even among
> commercial developers with MSDN subscriptions, it is common to delay
> upgrading to the lastest VC++ for a year or two or even three.  

This doesn't affect LLVm because nobody ever tried compiling this with
older VC++ versions. I'm advocating the latest so that we have fewer
"upgrade" problems going forward.

> I've
> personally been involved with two such upgrades, from 5 to 6 and 6 to
> 7.1 and it's a pain.  

I sympathize, that's why I'm trying to push the compiler version as far
forward as possible to avoid pain later on.

> The project files are not converted correctly.

We won't use VC++ project files. You'll still have to compile with
cygwin tools. There's just too many other dependencies (flex, bison,
awk, sed, grep, gmake) ..

> Code that compiled before no longer does.  Code that does compile no
> longer runs correctly.  You depend on some third-party library that
> hasn't itself upgraded to the latest VC++ (still a problem with 7.1). 

Again, while I can sympathize, this problem doesn't affect LLVM because
we have no legacy of compiling on Win32.

> And don't even think of doing this near the end of a release cycle for
> your product.  The mere thought of using a /beta/ version of a Microsoft
> product...

Yes, this is more of a concern to me. That's why I suggested using the
update as well. While we'll be bleeding edge for a while, eventually
VC++ 8 will be released and its SP1 will make it actually work
correctly. If we start adjusting for its quirks now, we can (hopefully)
have something reasonably stable by the time lots of Win32 people start
using LLVM.

> 
> And for those without an MSDN subscription, the cost of purchasing the
> latest Visual Studio is enough disincentive.

Another reason why I suggested the free download alternative ;>

> If the LLVM code base doesn't want to compile with VC++ 6 because it's
> not sufficiently ANSI compliant, that's a good enough reason to not
> support it.  

That's exactly the reason.

> I know that template support wasn't very compliant with 6
> (though still better than most non-g++ Unix compilers even today) and
> LLVM uses templates a lot.  While 6 is still common, by now most are
> switching to 7.1.  As it seems to work well enough with 7.1, I don't
> think standardizing on an unreleased version that won't become dominant
> for four years or so is constructive.  And that assumes it actually
> ships in 2005 :)

I agree there's some risk and I think we should make our attempt to have
it compile with VC++ 7.1 (thanks Paolo!). However, LLVM requires a
standards compliant compiler. If 7.1 isn't up to the task, then we can't
use it. So far, the changes needed in LLVM have been minor so it hasn't
been a problem. However, we're not going to bastardize the code base
just to support a compiler that isn't up to snuff.

I think you're right that "standardization" on the VC 8 compiler is
somewhat risky. We should continue the 7.1 effort while also using
8(beta) and when 8 is ready, then it should become the standard for
windows (assuming it actually implements the C++ standard correctly!)

Reid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040915/10c30e44/attachment.sig>


More information about the llvm-dev mailing list