similar to: [LLVMdev] VS build is broken again

> 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

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 work. > Moreover, I'd be content with a build system that

Chris Lattner <sabre at nondot.org> writes: [snip] > Others have suggested alternative build systems before like cmake. > Apparently cmake can autogenerate VC++ and Xcode project files from > the same thing that it builds from on unix systems. cmake creating VC++ project files does not appeal much to me. First, project files are not mandatory for using MS compiler. Second,

On May 17, 2008, at 2:44 PM, Óscar Fuentes wrote: > I don't know how much LLVM build system is tied to the GNU toolchain > or > how much it depends on *nix features, but suppossing that adding > support > for MSVC++ is impractical, perhaps it would be simpler to implement a > Makefile-based build system for MSVC++ than to keep up to date the > project files. This would

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

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

Hi Dmitri, For what version of VS did you update the project files? Ted On May 17, 2008, at 3:00 PM, Dmitri Makarov wrote: > 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. > > > Index: win32/Analysis/Analysis.vcproj

Hi Dmitri, I know what you are saying, but in the end I think we are lucky if diffs against project files have any meaningful information. Nobody right now assumes responsibility for regularly updating the VS files, so we routinely get patches from different people when they decide to upgrade the project files, and these patches change the .sln files in arbitrary ways. If you have

I too have done some work on an alternative build system for llvm. It is based on boost.build. Of course, it's quite a large project and I'm not ready to contribute the work yet. Ideally I was hoping to replace all of makefile functionality with jamfiles. Boost.build is attractive because support for new compilers/tools comes with new releases of boost.build and need not be added

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

On May 17, 2008, at 11:51 PM, Dmitri Makarov wrote: > This in effect adds codegen.lib to the > list of libraries linked into clang.exe and solves all the unresolved > symbol errors in the clang build. I would submit the diff, but it > looks like visual studio changes all the encodings of projects in the > .sln file, so the diff includes a lot of irrelevant lines. Changes all the

> 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

Cyrille Berger wrote: > On Sunday 18 May 2008, Óscar Fuentes wrote: >> Chris Lattner <sabre at nondot.org> writes: >> >> [snip] >> >>> Others have suggested alternative build systems before like cmake. >>> Apparently cmake can autogenerate VC++ and Xcode project files from >>> the same thing that it builds from on unix systems. >>

On Sunday 18 May 2008, Óscar Fuentes wrote: > Chris Lattner <sabre at nondot.org> writes: > > [snip] > > > Others have suggested alternative build systems before like cmake. > > Apparently cmake can autogenerate VC++ and Xcode project files from > > the same thing that it builds from on unix systems. > > cmake creating VC++ project files does not appeal

Stefanus Du Toit <sdt at rapidmind.com> writes: [snip] > We have considered contributing such a build system, and if we were to > do so would probably base it on SCons (http://www.scons.org/) because > we already use SCons extensively. At first, SCons is what I intended too. But then I read about the KDE experience and took the safe route :-) [snip] > Are you intending

Hi > For what it's worth, I think that using a system like cmake, while > lessening the load of the LLVM developers, increases the load on users of > LLVM. Well if it is easy to use, i don't think that is a problem? Besides is extendig llvm also an "use case" in this sense? > In my opinion the best solution is if the software comes with project >

ST wrote: >> In my opinion the best solution is if the software comes with project >> files/makefiles that are 'native' to the platform you're building on and >> doesn't require any extra software to be installed before you can build. >> I've had good results with using scripts to keep .vcproj files updated in >> order to synchronize project files

On May 17, 2011, at 2:50 AM, Eric Niebler wrote: > On 5/17/2011 2:58 AM, Eric Christopher wrote: >> On May 14, 2011, at 3:08 AM, Eric Niebler wrote: >> >>> Just a heads up that the llvm build appears to be broken on cygwin. I >>> haven't investigated, but here's the failures: >>> >>> llvm[3]: Compiling X86ISelDAGToDAG.cpp for