similar to: [LLVMdev] VS2005 patch

The project files need frequent updating. I cannot maintain VS2005 project files, so while they could be distributed with LLVM, they will become broken fast. Also, VS2003 and VS2005 project and solution files cannot coexist in the same directories, further complicating matters. Aaron Gray wrote: > Hi Morten, > > If you can make the VS2005 project files availiable on the net then I

_CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in VS2003. Morten Ofstad wrote: > Jeff Cohen wrote: > >> The project files need frequent updating. I cannot maintain VS2005 >> project files, so while they could be distributed with LLVM, they >> will become broken fast. Also, VS2003 and VS2005 project and >> solution files cannot coexist in

The new property manager doesn't exist in VS2003 either. Don't know where to add it. Chris Lattner wrote: > On Fri, 27 Jan 2006, Jeff Cohen wrote: > >> _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it >> in VS2003. > > > It shouldn't hurt to define it though, even if VC2003 where it does > nothing. Right? > > -Chris >

On Fri, 27 Jan 2006, Jeff Cohen wrote: > The new property manager doesn't exist in VS2003 either. Don't know where to > add it. Isn't there a place to add -D_CRT_SECURE_NO_DEPRECATE for the preprocessor? Isn't this all we are talking about, or am I missing something? -Chris >> On Fri, 27 Jan 2006, Jeff Cohen wrote: >> >>> _CRT_SECURE_NO_DEPRECATE

On Fri, 27 Jan 2006, Jeff Cohen wrote: > _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in > VS2003. It shouldn't hurt to define it though, even if VC2003 where it does nothing. Right? -Chris > Morten Ofstad wrote: > >> Jeff Cohen wrote: >> >>> The project files need frequent updating. I cannot maintain VS2005 >>>

OK, fixed the problem with the intrin.h header that doesn't exist in previous versions of VS... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JIT.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060126/7e55b0d0/attachment.ksh>

I don't know. If that's all it was, why is there a special new property manager to set it? Morten will need to explain what to do in VS2003 to make VS2005 happy. Chris Lattner wrote: > On Fri, 27 Jan 2006, Jeff Cohen wrote: > >> The new property manager doesn't exist in VS2003 either. Don't know >> where to add it. > > > Isn't there a place to

Jeff Cohen wrote: > The project files need frequent updating. I cannot maintain VS2005 > project files, so while they could be distributed with LLVM, they will > become broken fast. Also, VS2003 and VS2005 project and solution files > cannot coexist in the same directories, further complicating matters. The VS2003 project files convert without problems -- you might want to add in

Hi Morten, If you can make the VS2005 project files availiable on the net then I can test them as I have VS2005 now, so then with Chris'es okay then they could be distributed with LLVM. Thanks, Aaron ----- Original Message ----- From: "Morten Ofstad" <morten at hue.no> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, January 26,

Hello Jeff, Jeff Cohen wrote on 28/01/2006 at 11:43 a.m.: > I don't know. If that's all it was, why is there a special new property > manager to set it? Morten will need to explain what to do in VS2003 to > make VS2005 happy. IMHO all you need to do is go to Project properties -> C/C++ -> Preprocessor definitions and add _CRT_SECURE_NO_DEPRECATE Best regards,

Jeff Cohen wrote: > Morten Ofstad wrote: >> Jeff Cohen wrote: >> >>> The recent issues concern the head revision, post 1.9. As no one has >>> ever submitted patches to fix 2005 problems with the 1.9 release, it is >>> safe to say they still exist. >>> >> >> For the 1.5 release I submitted patches that made everything compile

Might I make a suggestion? I manage a few rather large cross platform projects which include embedded targets, Windows OS w/ multiple Visual Studio targets (2003, 2005, and 2008), and some Linux flavors. In the past we hand built all the makefiles and manually maintained the Visual Studio project / solution files, which has always been a pain. Recently we've made a successful partial

Please note that I'm not advocating CMake as a replacement for autotools or another build environment - what I was postulating is that CMake may provide an easier to maintain option for generation of Visual Studio project and solution files, which unless I'm mistaken the GNU autotools suite does not support. Used in this manner they provide the ability to generate these for at least

On Thu, 26 Jan 2006, Morten Ofstad wrote: > OK, fixed the problem with the intrin.h header that doesn't exist in previous > versions of VS... applied, thanks! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060123/031225.html -Chris -- http://nondot.org/sabre/ http://llvm.org/

Tom Grandgent a ?crit : > If you remove the project files, I doubt it's going to make things easier > for anyone. You'll probably just increase the number of questions as > people struggle to compile using less common and less user-friendly > methods, and someone is going to have to maintain that anyway. And how is having out-of-date project files help. > VS users want

On Thu, Oct 2, 2008 at 12:07 AM, Jean-Marc Valin < jean-marc.valin at usherbrooke.ca> wrote: > Tom Grandgent a ?crit : > > If you remove the project files, I doubt it's going to make things easier > > for anyone. You'll probably just increase the number of questions as > > people struggle to compile using less common and less user-friendly > > methods,

Hi, Is is possible to have makefiles, batchfiles, whatever that just calls the command-line compilers and doesn't require this huge amount of per-compiler-version crap? Otherwise, I'm seriously considering removing all those project files from the build since time has proven there's just no way to get them up-to-date. Jean-Marc Alexander Chemeris a ?crit : > Hello, > > On

Hello, This is my first post on this mailing list, so bear with me... My name is Morten Ofstad and I work for Hue AS (www.hue.no), a company that makes 3D Visualization software. We are looking into using LLVM for JIT compiling shader programs, to replace our own (slow) VM. A requirement for this is that we can compile LLVM in VS7.1, so I contacted Paolo Invernizzi to find the status of his

Hello, On Wed, Oct 1, 2008 at 8:29 PM, Kerry Bonin <kerry at vscape.com> wrote: > - Anyone else see this? > - Who maintains the Win32 projects (at least the VS2005)? I'd be happy > to work with to solve. > - If nobody is actively maintaining this build, I'd be glad to fix and > contribute back. I'm currently listed as a Win32 build system maintainer, but I

Ok! If there are indeed cross-compiling targets defined, then vs2005 projects probably should be maintained. In any case, this is all up to Jean-Marc, since he's the one that actually has authority to change it :) Jean-Marc -- what's your opinion? On 11/28/07, Aron Rosenberg <arosenberg@sightspeed.com> wrote: > > I pulled the test directory from 2003, but everything else