similar to: [PATCH] Add CMake build script

> > What do you want to improve exactly? Do you experience > problems? > not only iterator.h but also DataTypes.h I also put back iterator.h because at the trunk of llvm, iterator.h.in and iterator.h.cmake still there:( My improvement is now we didn't to generate DataTyes.h, we just need to generate config.h, And everything is configured at config.h, but not in seperate files.:)

For Mac OS X, we have malloc_zone_statistics() defined <malloc/malloc.h>, however, if we don't define HAVE_MALLOC_ZONE_STATISTICS, that function won't be used and we will get warnings like: lib/System/Unix/Process.inc:68:2: warning: #warning Cannot get malloc info on this platform This patch enables this function in cmake build. --- cmake/config-ix.cmake | 1 +

Le 24 oct. 08 à 10:01, Cyrille Berger a écrit : > On Friday 24 October 2008, Óscar Fuentes wrote: >> Apart from me, I only know of one person that tried CMake, and it >> was by >> accident. > > Well I tried it on linux, and it sounds like it worked. Well llvm > was build > without error, but since I prefer to stick to released llvm, I > didn't if the

Hi, I'd like to link Clang against the STP theorem prover. Since Clang is built by the LLVM build system, I hope this is the correct place to ask for advice. The attached patch allows me to pass `configure` a --with-stp option and provide a path to the install prefix for STP. However, I am not familiar with autoconf, so I am not confident that my changes are the correct way to do this. I

Hi Yonggang! On Aug 27, 1:02 pm, 罗勇刚(Yonggang Luo) <luoyongg... at gmail.com> wrote: > Because this patch must be applied in one time so that don't broken > the buildbot system. > So I just submit the configure and cmake at the same time. > Also, this patch add two new file > iterator.h > and > DataTypes.h What do you want to improve exactly? Do you experience

Because this patch must be applied in one time so that don't broken the buildbot system. So I just submit the configure and cmake at the same time. Also, this patch add two new file iterator.h and DataTypes.h for the reason that patch doesn't support for svn's rename mechanics. So I just add these two file and doesn't delete the old history files Because I doesn't get

Hi, On 2017-02-01 23:20:40 -0800, Andres Freund wrote: > > Can you give a pointer to the patch so that I can assess the rough > > complexity? If it's simple enough, I'd be happy to help get it > > reviewed and in. If it's more complicated, I probably won't have the > > time to assist. > > Patch (and a prerequisite) attached. Took me a while to get

On Friday 24 October 2008, Óscar Fuentes wrote: > Apart from me, I only know of one person that tried CMake, and it was by > accident. Well I tried it on linux, and it sounds like it worked. Well llvm was build without error, but since I prefer to stick to released llvm, I didn't if the results of the compilation was usuable ;) -- Cyrille Berger

Mike Stump <mrs at apple.com> writes: > On Oct 23, 2008, at 5:04 PM, Óscar Fuentes wrote: >> Now tblgen.exe builds fine with my CMake build system. Guess it is >> the same case for the VC++ project files. > > Oh, does clang building work with CMake? If not, wanna cons it > up? :-) Thanks. Giving a compelling reason why you'll like to build clang using

I don't know since when, but this file has been changed to remove all the trickery (aka defines) needed for MinGW-w64 (and probably everything else that as forgotten) to succesfully compile it. Attached is a patch that reintroduces the compiler checking. I would like to see this in LLVM 3.0, otherwise (by the looks of the reintroduced code) anything newer than _MSC_VER_1500 will be broken.

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that