similar to: [LLVMdev] VC++ port broken for now

----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfile or directory Date: Tue, 21 Dec 2004 16:29:47 -0800

----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor directory Date: Thu, 23 Dec 2004 08:05:39 -0800 >Yes, it

Yes, it should find windows.h with the default configuration. But you have to be suspicious of beta code that Microsoft gives out for free. It might just be very buggy, or it might be deliberately crippled. Considering the price tag on Visual Studio, it's one or the other (and probably both). Out of curiosity, did it accept the solution and project files as is, or did it want to

I agree completely with you, Jeff. However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk). And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC

Hi Jeff and Morten, I was just wondering if below wisdom is true, why not prefix every solution and project file with VC71 in front of the file name to signal the case that it is only designed for that specific IDE/tool? This gives us room for comming up with other solution and project files for another MS specific IDE/tool independt of each other. Henrik. ----Original Message Follows----

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS. There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be

I have some patches of my own: * An improvement on Morten's fix to Signals.cpp. * Undo the breakage to system.vcproj (Signals.cpp was being built twice as a result). * Fix a class/struct inconsistency. * Remove unneeded #includes from win32 fSystem files. I've also determined why VC++ complains about deprecated destructors when using hash_map. Because it's not ANSI (yet),

Henrik Bach wrote: > ----Original Message Follows---- > From: Jeff Cohen <jeffc at jolt-lang.org> > Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List > <llvmdev at cs.uiuc.edu> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': > No suchfileor

>>I've also determined why VC++ complains about deprecated destructors >>when using hash_map. Because it's not ANSI (yet), Microsoft decided to >>move it from the std namespace to the stdext namespace. Use of >>std::hash_map is therefore deprecated. Similar shenanigans have been >>committed by gcc from one version to another. I see where this is

Windows.h is part of Microsoft's Platform SDK that's bundled with Visual Studio. It should never have been in the llvm source tree. Why don't you have it? You have VC++, right? Henrik Bach wrote: > Hi, > > I cannot find windows either... In previous llvm sources windows.h was > found in: 'include/llvm/Config'. > > ------ Build started: Project:

Jeff, On Mon, 2004-11-15 at 21:43, Jeff Cohen wrote: > I have some patches of my own: > > * An improvement on Morten's fix to Signals.cpp. > > * Undo the breakage to system.vcproj (Signals.cpp was being built twice > as a result). > > * Fix a class/struct inconsistency. > > * Remove unneeded #includes from win32 fSystem files. > Thanks for the

When I ran configure after updating, I get various errors. First: % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc checking for a BSD-compatible install... /usr/bin/install -c checking build system type... i386-unknown-freebsd5.2.1 checking host system type... i386-unknown-freebsd5.2.1 checking target system type... i386-unknown-freebsd5.2.1 test: Unknown: bad

On Mon, 30 Aug 2004 20:48:45 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > When I ran configure after updating, I get various errors. First: > > % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc > checking for a BSD-compatible install... /usr/bin/install -c > checking build system type... i386-unknown-freebsd5.2.1 > checking host system

Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at

Hi, I cannot find windows either... In previous llvm sources windows.h was found in: 'include/llvm/Config'. ------ Build started: Project: support, Configuration: Release Win32 ------ Compiling... randtable.c c:\projects\src\llvm-1\llvm\lib\Support\bzip2\bzlib.h(117) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory huffman.c ----------------

The recently added code: static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty, -INFINITY); if (V2->isNullValue()) return 0; BuiltinType R = (BuiltinType)V1->getValue() / (BuiltinType)V2->getValue(); return

Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at

Yes, that will work. I'll make the change. Chris Lattner wrote: > On Mon, 2 May 2005, Jeff Cohen wrote: > >> The recently added code: >> static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { >> if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); >> if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty,

On Mon, 2 May 2005, Jeff Cohen wrote: > The recently added code: > static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { > if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); > if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty, -INFINITY); > if (V2->isNullValue()) return 0; > BuiltinType R =

It would be great to avoid STLPort and use plain vanilla VC... as I told, the biggest difference it's how the hash_map and hash_set are implemented, but I'm not so strong in C++ for resolving the iussue. About the build procedure, it's based on scons, and it's still at a very preliminary stage... Right now I'm trying to build TableGen with it, as till now I've always