similar to: [LLVMdev] VS build is broken again

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

Reminder... Round one has been committed as <http://llvm.org/viewvc/llvm-project?view=rev&revision=107432> I hope that it got digested by now, as I plan to commit the second round tomorrow. In fact I made two test commits already: r107480 and r107580, the former of which actually uncovered some more uses of the low-level interfaces in core LLVM that have slipped through. To be

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

Sounds great to me Gabor. I really like your new incremental approach to this patch set. -Chris On Jun 30, 2010, at 1:59 PM, Gabor Greif wrote: > Hi all, > > I am almost ready for the last step with landing my long-standing patch. > I have converted (almost) all low-level interface users of CallInst to > respective high-level interfaces. What remains is a handful of hunks >

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

Hello, Everyone > IMHO, the only way to keep MSVC build up to date is to monitor the > commits mailing list watching for changes on the makefiles, reflect the > change on the MSVS build and test it. LLVM make system is built with "compile everything in directory" principle, so it just globs for the list of .cpp files and builds all of them. Thus, no changes to makefiles are

Gabor Greif wrote: > Am 30.06.2010 um 23:31 schrieb John Criswell: > > >> Stupid question: is making the getOperand() method of CallInst >> going to work? For example, if I have the following code: >> >> void >> method (Instruction * I) { >> I->getOperand(2); >> ... >> } >> >> void method2 (CallInst * CI) {

On Apr 21, 10:59 pm, "Tanya M. Lattner" <to... at nondot.org> wrote: > On Mon, 21 Apr 2008, Gabor Greif wrote: > > Hi all, > > > can anybody confirm that llvm-gcc is broken? > > It builds for me on x86, darwin8 (svn rev: 50048). What are you using to > configure it? This is what gcc/config.log remembered: $ /Users/ggreif/llvm-gcc/gcc/configure

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

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

While cleaning up 80col violations, I stumbled upon ggreif at my [!2464] find lib -name SimplifyCFG.cpp lib/Transforms/Utils/SimplifyCFG.cpp lib/Transforms/Scalar/SimplifyCFG.cpp I do not believe this is good, especially IDEs tend to confuse files with identical names coming from different directories. (CodeWarrior did.) Should we rename one of them? Cheers, Gabor

Am 30.06.2010 um 23:31 schrieb John Criswell: > > Stupid question: is making the getOperand() method of CallInst > going to work? For example, if I have the following code: > > void > method (Instruction * I) { > I->getOperand(2); > ... > } > > void method2 (CallInst * CI) { > method (CI); > ... > } > > Will method() still work

Gabor Greif wrote: > Hi all, > > I am almost ready for the last step with landing my long-standing patch. > I have converted (almost) all low-level interface users of CallInst to > respective high-level interfaces. What remains is a handful of hunks > to flip the switch. > > But before I do the final commit I'd like to coerce all external users > to code against the

Benjamin Kramer wrote: > On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > >> Hi all, >> >> I am in charge of the controlled introduction of clang into >> our builds at my workplace. Since all our tools must run from >> a ClearCase view for automatic dependency tracking, we have been >> biten by a Linux bug, and

On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > Hi all, > > I am in charge of the controlled introduction of clang into > our builds at my workplace. Since all our tools must run from > a ClearCase view for automatic dependency tracking, we have been > biten by a Linux bug, and readlink("/proc/self/exe", ...) gives >

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 Fri, 16 Mar 2012 10:32:47 +0100 Gabor Greif <ggreif at gmail.com> wrote: > Hi all, > > at my paid job I am pushing the Clang/LLVM combo into evaluation (we > currently use a gcc3.4 generation toolchain). Great! Since we produce for the > embedded domain we need a reliable > host (i.e. simulation i686) / target (PPC) dual setup. To this end I > almost succeeded

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

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 >

> 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