similar to: [LLVMdev] Final Visual Studio 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)...

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

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

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

If you're getting this error in lib/System/Win32/TimeValue.cpp, then you are not building it correctly. This file is included by lib/System/TimeValue.cpp, which is what you ought to be building. None of the files under Win32 are to be compiled directly; they are all included by files in lib/System. On Mon, 01 Nov 2004 11:14:18 +0100 Morten Ofstad <morten at hue.no> wrote: > Hello,

While a single mechanism is best in principle, it *is* possible to come up with one so complicated or unfamiliar that it is harder to use on all platforms. The Windows and *nix development worlds seem different enough that there is a risk of ending up like this. I'm not objecting to trying to create a unified build system, but I think it's worth considering whether the result

> 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

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. Until then, I strongly suggest a repository for the msvc project files until we'll come with a lasting solution. It is natural that we, msvc guys, should keep these files in shape. Henrik.

On Nov 2, 2004, at 8:38 AM, Reid Spencer wrote: > 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

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

Vikram S. Adve wrote: > Another alternative may be to unify the LLVM-side information > (opt/debug options, tool names, directories, test scripts, etc.) so > that most tasks only require you to make changes in one place, and then > let the rest of the build system be separate for the two platforms. I think it's OK to have a seperate limited (only the core libraries) native

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

On Tue, 2 Nov 2004, Morten Ofstad wrote: > > 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 That sounds good. > could require cygwin to be installed and use the unix

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

I moved my own llvm tree out of the way and tried to get a fresh copy from cvs and build everything from scratch... and it worked! apart from one little problem, a file was moved and should be removed from the project files -- here is a patch. There is a small problem with submitting patches for the .vcproj files - VS saves them with CRLF line endings but the CVS versions appear to have only

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

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,

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