similar to: [LLVMdev] Excluding project builds

Dan Liew <dan at su-root.co.uk> writes: > On 7 July 2015 at 15:05, David A. Greene <greened at obbligato.org> wrote: >> I'm learning the cmake build. >> >> Is there a way to disable the build of a subdirectory in llvm/projects? >> I'm getting a build error on one project and don't want it to hold up >> the build of everything else. >

I am an actual end user of LLVM who builds it from source and not a developer of it so I think I have an important perspective that is not represented here. Also I am pretty sure the llvmdev mailing is heavily biased and might not reach actual end users of LLVM. I use the Autotools build system for a number of reasons. If compromises or reasonable workarounds could be found I would be okay with

On 6/21/2012 1:21 PM, Douglas Gregor wrote: > > On Jun 20, 2012, at 5:13 PM, Nick Lewycky <nlewycky at google.com > <mailto:nlewycky at google.com>> wrote: > >> Is there anybody who is certain that our autoconf dependency needs to >> stay around? Are there developers stuck on systems that don't have a >> recent enough cmake in their most recent

2012/6/23 Joshua Cranmer <pidgeot18 at gmail.com>: > I decided to try recently to do one of my builds with cmake instead of > configure. The problem I hit is before I even try compiling in the first > place: cmake /src/llvm --help produces an extremely useless list of options, > so it's impossible to figure out how to configure it with cmake without > looking up online.

Is there an equivalent "make check-all VERBOSE=1" in the CMake build? I'm looking to see the full list of unit tests and the result of each. Thanks, Greg

On Tue, Aug 17, 2010 at 11:09 PM, David A. Greene <greened at obbligato.org> wrote: > Please do.  7z is not supported on Linux. Does not this work? http://packages.debian.org/lenny/p7zip-full Eugene

greened at obbligato.org (David A. Greene) writes: > Actually git pull can sometimes get you into trouble. Probably git > fetch / git rebase is the better combination for LLVM. I don't get it. Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > greened at obbligato.org (David A. Greene) writes: > >> Actually git pull can sometimes get you into trouble. Probably git >> fetch / git rebase is the better combination for LLVM. > > I don't get it. > > Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? No. It does

Sanjoy Das <sanjoy at playingwithpointers.com> writes: > In short, I propose a intrinsic based approach which hinges on the > concept of a "parallel map". The immediate effect of using intrinsics > is that we no longer have to worry about missing metadata. Moreover, > we are still free to lower the intrinsics in a variety of ways -- > including vectorizing them or

greened at obbligato.org (David A. Greene) writes: > greened at obbligato.org (David A. Greene) writes: > >> For now, I think if I tweak the way I do the build to always build >> without pointing to llvm-gcc first, build and test LLVM then build >> llvm-gcc and re-build LLVM, it should work. It will take much longer, >> though. :( > > I updated the bug

Nikola Smiljanic <popizdeh at gmail.com> writes: > I'm not sure if this makes a difference but I ran this > > make -j 2 -k LLVMCC_OPTION=clang ENABLE_BUILT_CLANG=1 ENABLE_PARALLEL_REPORT=1 TEST=simple report > ../../report.txt 2>&1 That does indeed seem to get me further. Thanks! -Dave

On Aug 18, 2010, at 4:01 PM, David A. Greene wrote: > And the fact that Boostbook knows how to import Doxygen XML output is a > killer feature. Having a hardcopy of the Doxygen reference can be > really useful. > > I agree with Chris that at the moment, BoostBook/QuickBook is too hard > to set up. I'm certainly not about to use bcp magic and litter my > workspace with

On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote: > Sanjoy Das <sanjoy at playingwithpointers.com> writes: > >> In short, I propose a intrinsic based approach which hinges on the >> concept of a "parallel map". The immediate effect of using intrinsics >> is that we no longer have to worry about missing metadata. Moreover, >> we are still

Just FYI, we discovered that GNU binutils 2.17 has a nasty bug in the linker that causes excessive link time when building llvm. We switched to using cvs binutils and our link times went from minutes to seconds. I didn't see anything about this on the web pages. It might be good information to add to the Getting Started guide. -Dave

OvermindDL1 <overminddl1 at gmail.com> writes: > On Tue, Aug 17, 2010 at 5:25 PM, Chris Lattner <clattner at apple.com> wrote: >> On Aug 17, 2010, at 3:42 PM, OvermindDL1 wrote: >> >>> >>> On Tue, Aug 17, 2010 at 4:09 PM, David A. Greene <greened at obbligato.org> wrote: >>>> OvermindDL1 <overminddl1 at gmail.com> writes:

Óscar Fuentes <ofv at wanadoo.es> writes: > Okay, we can get rid of recursive make. However, as pointed out > elsewhere, removing recursive make will not make a difference on the > LLVM build. What David Greene says probably is related to difference > sizes among his compiler and LLVM. Ok, whatever. I'm done arguing experiences. -Dave

On Thu, 09 Dec 2010 11:24:19 -0600 greened at obbligato.org (David A. Greene) wrote: > greened at obbligato.org (David A. Greene) writes: > > > Often I run a few different builds in parallel, with different > > obj/build directories. Is it possible that the test infrastructure > > writes something to the source directories or some common temp > > directory? That

I'm just starting to dive into llvm, hoping to implement a good graph coloring register allocator. I gather that this has been discussed before. What is the RegAllocGraphColoring.cpp currently in the sources? It seems to be the Fred Chow algorithm but it's not mentioned in the documentation anywhere. Does it work? -Dave

On Mon, Aug 9, 2010 at 11:29 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > You are right that BoostBook is targeted directly for large C++ > projects, and I seriously considered BoostBook for this project, but > ran into a few road blocks. > > * It's tightly integrated into boost and makes quite a few assumptions > about that. What assumptions is that? On

On 6/16/07, David A. Greene <greened at obbligato.org> wrote: > Just FYI, we discovered that GNU binutils 2.17 has a nasty bug in the > linker that causes excessive link time when building llvm. We switched > to using cvs binutils and our link times went from minutes to seconds. > > I didn't see anything about this on the web pages. It might be good > information to