similar to: [LLVMdev] Small patch for visual studio project files

We could also do the "cvs admin -kb" thing on all the project files so that cvs won't do keyword expansion or line ending conversion. Thoughts? Reid. On Mon, 2004-11-08 at 07:36, Jeff Cohen wrote: > You have to use a version of CVS that's specifically built for Windows. > You can find prebuilt Windows binaries at cvshome.org. The cygwin > supplied CVS no doubt

Jeff Cohen wrote: > Are you sure your CVS is configured correctly? On Windows, CVS > automatically converts between LF and CR/LF line endings. I sent a > patch to remove all CRs from the repository because when I checked out > the files on Windows, every line had two CRs and a single LF. When VS > saved a modified project file, the extra CR went away, causing every > line to

Are you sure your CVS is configured correctly? On Windows, CVS automatically converts between LF and CR/LF line endings. I sent a patch to remove all CRs from the repository because when I checked out the files on Windows, every line had two CRs and a single LF. When VS saved a modified project file, the extra CR went away, causing every line to diff. On Mon, 08 Nov 2004 12:10:21 +0100 Morten

You have to use a version of CVS that's specifically built for Windows. You can find prebuilt Windows binaries at cvshome.org. The cygwin supplied CVS no doubt thinks it's running on Unix, so naturally it won't convert line endings. On Mon, 08 Nov 2004 16:23:30 +0100 Morten Ofstad <morten at hue.no> wrote: > Jeff Cohen wrote: > > > Are you sure your CVS is

The Visual Studio project files that Morten Ofstad provided have been committed to CVS in the win32 directory. I would appreciate it if Morten and at least one other win32 developer could verify that the files work correctly as committed. Thanks, Reid.

I have problems getting the GNU tools to execute properly. I installed bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the README. The installers for these packages did not want to put them in the llvm/win32/{tools,share} directory, which is unfortunately where the project files expect them to be. I copied the files manually to these directories, but bison still refuses to

Two suggestions: 1. m4 might be located by your PATH variable. 2. Talk to Morten Ofstad about how he got it to work. Reid. On Wed, 2004-11-03 at 19:34, Jeff Cohen wrote: > I have problems getting the GNU tools to execute properly. I installed > bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the > README. The installers for these packages did not want to put them

I'll try and verify it later tonight. On Wed, 03 Nov 2004 08:18:51 -0800 Reid Spencer <reid at x10sys.com> wrote: > The Visual Studio project files that Morten Ofstad provided have been committed > to CVS in the win32 directory. I would appreciate it if Morten and at least one > other win32 developer could verify that the files work correctly as committed. > > Thanks,

Hello, with the patches you accepted last week, everything now works with two one-line modifications. One is a missing include in a windows specific platform file and the other is a definition of a symbol I need to trick the linker (as discussed before)... The attached file is the complete diff between my version and the CVS. If you want to put my visual studio project files into the CVS,

> Right. This is why I suggested we just put the project files in a simple > place that Windows folks can keep up to date and that won't get in the > way of the Unix folks. I have them in llvm/win32 ... There is another solution though, you could require cygwin to be installed and use the unix build system but with the VS command line tools. The 'check' target should be

Jeff Cohen wrote: > On Tue, 02 Nov 2004 10:25:39 +0100 > "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > > >>I've come over an open source script which should be able to convert unix >>(gnu?) like makefiles to nmake. However, It possible needs some changes to >>work with the llvm makefile framework. > > > I'm very

defining __STDC_LIMIT_MACROS on the command line is not really necessary for Visual Studio, and is a bit of a pain when you want to include the LLVM headers from your own project, so I moved the check a bit down into the Unix case to avoid the hassle... Here is a patch On a side note, everything is going well so far with integrating LLVM into our application - I was very happy when I found

Vikram Adve wrote: >> Anyway, if anyone wants the VS project files just contact me. It's >> really a separate thing from the main project so I can see why you're >> reluctant to put it in the CVS. And, as said before, I think most >> windows users would prefer a binary distribution anyway so the ease of >> building the windows version from source is

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 correctly with VS2005, I think there are some mails in the archives about the issues I ran into. I also submitted patches

On Mon, 1 Nov 2004, Morten Ofstad wrote: > with the patches you accepted last week, everything now works with two > one-line modifications. Great! > One is a missing include in a windows specific > platform file and Okay, as Jeff pointed out, this isn't needed, so not applied. > the other is a definition of a symbol I need to trick the linker (as > discussed before)...

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 correctly with VS2005, I think there are some mails

Morten Ofstad wrote: > > Well, actually I'm speaking mostly for myself ;-) I have a front end, I > want to generate code, all I really need is a llvm.lib and the include > files that go along with it... I imagine this is quite a common > scenario, but I might be wrong. This is pretty much my usage scenario too, however I expect to be *able* to hack on the source and

We could add the MSVS project files to the repository but I too would like to see a single mechanism for building on all platforms. Someone mentioned using the Boost build system a few weeks ago but I haven't heard anything more on how that effort is going. I also think we can customize our existing makefiles to use the underlying (command oriented) tools under MSVS. We'd still need

Hi, you might or might not want to take these patches, as they are basically just meant to shut VS up. For LLVM this does not matter much, but when I include the public headers in my own app I prefer not to get tons of warnings, so I fixed the ones I got all the time... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

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