similar to: [LLVMdev] Question for users of the CMake build system:

Hi, We use CMake but don't use that setting. Cheers, James On 29 June 2012 12:40, Chandler Carruth <chandlerc at google.com> wrote: > Do you use the LLVM_INCLUDE_TESTS setting? If so, what for? > > > It is documented to preclude the inclusion *unittests* in the build. > > What it actually does in preclude *all* LLVM testing (unit and regression), > but only

I'm happy to have this in the main LLVM repositiory. The version in the test suite should likely stay there because the test suite should be buildable w/o LLVM itself -- it is largely a distinct thing. We re-use lit, but not much else from LLVM, and we wouldn't want to install the benchmark library the way we do lit. One interesting point: we should have some way of running the in-tree

And one more question regarding ASan cmake build. Currently unittests are fine, but regular "clang -faddress-sanitizer" is not: current cmake build stores libclang_rt.asan-x86_64.a together with all the LLVM libs (in $build_path/lib/libclang_rt.asan-x86_64.a), but the Clang driver looks for asan runtime in clang resource dir:

Manuel, After the discussion at last night, I have agreed that GetTemporaryDirectory() on Win32 would do bad thing, thank you. dir = GetTemporaryDirectory(); dir.eraseFromDisk(erase_contents = true); dir = GetTemporaryDirectory(); /* It doesn't create anything on Win32 due to caching */ I suppose Manuel wants GetTemporaryDirectory() to keep semantics similar mkdtemp(3). Though it is in

Writing a more thought-out reply.... On Tue, Nov 12, 2013 at 9:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 12, 2013, at 7:04 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I have some concrete use cases in testing the pass manager where it will > allow the tests of this API to be more thorough, less verbose, and easier > to

Eric Christopher <echristo at apple.com> writes: > On Nov 8, 2011, at 7:20 PM, David A. Greene wrote: > > I couldn't figure out how to run the test-suite. Are there up-to-date > instructions somewhere? llvm-gcc doesn't exist anymore... > > Easiest is to check out the test-suite branch into projects and then after you configure and build from the top

On Wed, Jul 11, 2012 at 10:03 AM, Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jul 11, 2012 at 3:06 PM, Alexey Samsonov <samsonov at google.com>wrote: > >> And one more question regarding ASan cmake build. >> Currently unittests are fine, but regular "clang -faddress-sanitizer" is >> not: >> > > As a side note: I

It's also likely that a lot of '#include "foo.h"' can be replaced with 'class foo;' Especially in the transitive inclusion case, instead of removing the #include entirely. On Wed, Dec 6, 2017 at 8:38 AM, Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I, for one, want faster builds. > > Beyond that though, this seems like obvious

On Tue, Jun 26, 2012 at 12:37 AM, Alexey Samsonov <samsonov at google.com> wrote: > > > > On Tue, Jun 26, 2012 at 11:06 AM, Chandler Carruth <chandlerc at google.com> wrote: >> >> On Mon, Jun 25, 2012 at 7:38 AM, Kostya Serebryany <kcc at google.com> wrote: >> > >> > >> > >> > On Mon, Jun 25, 2012 at 5:43 PM, Kostya

On Nov 14, 2013, at 3:16 AM, Chandler Carruth <chandlerc at google.com> wrote: > Personally, I rather not do this, without very clear and compelling reasons. > > I understand that this could be very useful for your bringup (and so could be very useful locally), but once the passmanager is the default, it will get lost of in-tree testing by just about everything in the compiler.

On Tue, Jun 26, 2012 at 11:06 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Mon, Jun 25, 2012 at 7:38 AM, Kostya Serebryany <kcc at google.com> wrote: > > > > > > > > On Mon, Jun 25, 2012 at 5:43 PM, Kostya Serebryany <kcc at google.com> > wrote: > >> > >> > >> > >> On Mon, Jun 25, 2012 at 4:00 PM,

Thank you very much for the feedback! What Chandler said about test-suite totally makes sense to me since it's also excluded from LLVM git monorepo. I will try to land benchmark library to LLVM core repo and update it to the latest version. I have not been doing much CMake/project structure before, but I'll start looking into that next week. I'll reach out to Dominic if anything goes

On Thu, Nov 14, 2013 at 10:58 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 14, 2013, at 3:16 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > However, when we are adding interfaces or generic utilities to LLVM > (admittedly, not the common case) I don't think we do ourselves any favors > by using only half of the available tools to write

G'Day Tanya, Is it too late to bring in the following patches to fix some major brokenness in the AuroraUX tool chain for 2.6? http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84468&r2=84469&view=diff&pathrev=84469 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84265&r2=84266&view=diff&pathrev=84266

Sorry to trouble you, great software, I have it on Ubuntu 14.10, Windows 10 and now I was trying ARM: I have been trying to build a working Cland+LLVM for 4 days now, ARM Radxa Rock Pro Quad 1.6Ghz 2GB memory I'm building on an SD card, I tried 4GB and died(space thing), 8GB and died(again with the space thing) so I read everything I could find on building only a minimum testing build and I

On Wed, Jul 11, 2012 at 3:06 PM, Alexey Samsonov <samsonov at google.com>wrote: > And one more question regarding ASan cmake build. > Currently unittests are fine, but regular "clang -faddress-sanitizer" is > not: > As a side note: I don't like that the current cmake machinery builds asan tests by explicitly passing libclang_rt.asan-x86_64.a. IMO it needs to use

Currently these leave in lib/Transforms/ObjCARC even though they are analysis passes. This seems confusing and odd. In particular, Analysis/Passes.h talks about ObjCARCAliasAnalysis. =/ I'd like to just move the analysis headers to live under include/llvm/Analysis and the source under lib/Analysis. This will preclude omitting the ObjC ARC analysis passes from your build of LLVM if you

Hey all, IWYU maintainer here. I wanted to make a small observation. Surprisingly, IWYU will most often *add* includes to a reasonably well-factored codebase, and this ties into Chris' comment: > Beyond that though, this seems like obvious > goodness to reduce coupling in the codebase. Just blindly removing includes will probably increase coupling, not reduce it, because it optimizes

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

I want to start using cmake+ninja instead of autoconf for configuring and building llvm from svn, but I have no idea how to map my existing list of autoconf flags to cmake. Here's how I run ./configure right now in the top directory: PREFIX=_some_prefix_dir_ \ ../llvm/configure \ --prefix=$PREFIX \ --libdir=$PREFIX/lib/llvm \ --sysconfdir=$PREFIX/etc \ --enable-shared \