search for: nebraskin

I'm building llvm in MSVS 2008. LoopUnroll.cpp includes UnrollLoop.h line 23: #include "llvm/Transforms/Utils/UnrollLoop.h" but there's no UnrollLoop.h anywhere to be found. My svn tree is synced to TOT. What am I missing?

SimplifyLibCalls.cpp is no longer part of Transforms\IPO and Transforms\Scalar\SimplifyCFG.cpp is renamed to SimplifyCFG.cpp or something to that effect ( I didn't look up the actual checkins ). Having fixed that, I still can't get through the build: Creating library C:\work\s\llvm\win32\\bin\Win32\Debug/opt.lib and object C:\work\s\llvm\win32\\bin\Win32\Debug/opt.exp 1>opt.obj : error

Dmitri Makarov <nebraskin at yahoo.com> writes: >> Is it reasonable to ask > > Yes, it's reasonable. Since this is open source we depend on contributions from the community, etc... You know how the song goes. Seriously, I'll like to see a healthy MSVS build as much as you, but someone must do the...

> Is it reasonable to ask Yes, it's reasonable. Moreover, I'd be content with a build system that doesn't use MSVS IDE at all. If the build system could be parameterized to use microsoft cl compiler (cygwin gcc is useless for my purposes), e.g. something like in Boost project, I'd be more than happy to never care about VS project files. Yet, I want to limit my involvement

> I studied some a few years ago and concluded that it > was not worth the trouble. "Boost C++ Libraries" uses perforce jam ( in their case it's modified jam: bjam http://www.boost.org/doc/tools/jam/index.html ). Jam works well with massive structures of autonomous projects that constitute a collection of libraries and must be built on multiple platforms and with different

> Has anyone used cmake in a real system before? > Are there other worthwhile alternatives? Boost.Build may be a worthwhile alternative : http://www.boost.org/doc/tools/build/index.html

Ted, Attached is the diff against TOT. It makes the VS build work for me. Solution/project files work with VS 2005. Project files in clang need not to be modified. As it happens, the solution file for clang is part of the llvm tree ( go figure... ) Thanks Dmitri --- Ted Kremenek <kremenek at apple.com> wrote: > Hi Dmitri, > > I know what you are saying, but in the end I

Ted, Thanks for taking care of this. I found that in order to build clang (in addition to the vcproj changes I posted earlier today) I had to add a dependency such that the clangDriver project depends on the CodeGen (basically the CodeGen checkbox has to be checked in the list of the clangDriver's dependencies). This in effect adds codegen.lib to the list of libraries linked into clang.exe

attached is the diff of vcprojs that need to be changed to fix the VS build as of revision: 51224. I don't know if this catches all the missing bits, but this does build all the way through. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvs.patch URL:

If you look at an .sln file, there's a long sequence of digits associated with every project, something like this 8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942. For the lack of a better word I called it "encoding". After I changed the dependencies between projects in the solution, msvs replaced those numeric sequences by new ones literally for every project in the solution file. The diff now