similar to: PSA: svn tree conflict

Hi all, I've got https://reviews.llvm.org/D37756 up for review currently which simplifies a lot of the logic in our lit config files. For most people, this will be completely transparent and "just work", but it breaks one workflow that people should be aware of. Problem: If you run lit by putting llvm-config in your path and then running <source-root>/utils/lit/lit.py

llvm-lit is already put into <output-tree>/bin by CMake. There is a CMake target called `llvm-lit` that will generate the <output-dir>/bin/llvm-lit script. If you built only a few specific llvm targets such as FileCheck, etc then you may need to run this lit target manually. If you just run "ninja" for example, or "ninja check-llvm", it's automatically

Hi all, I've built llvm + clang on OS X 10.4 : Darwin 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc However, make check-all fails immediately with: Traceback (most recent call last): File "/Users/useruser/LLVM/llvm/utils/lit/lit.py", line 4, in ? import lit File

It looks like this broke green dragon: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173: note: Adding environment variables: {'DYLD_LIBRARY_PATH': '/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',

> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at google.com> wrote: > > I checked in a fix for that already, sorry for the trouble. I’m waiting for it to cycle awesome. Thanks! -- adrian > On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > It looks like this broke green dragon: > >

On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: > Hi all, > > As you may or may not have noticed, I have gradually been replacing > the testing infrastructure in LLVM. Most of this work is moving LLVM > and Clang to share a single testing tool, 'lit'. See: > http://llvm.org/cmds/lit.html > for documentation on the tool itself. > > If you haven't already

On Sun, Dec 8, 2013 at 9:04 AM, Alp Toker <alp at nuanti.com> wrote: > > On 08/12/2013 13:12, Chandler Carruth wrote: > >> >> * Removing trailing \ will introduce the neat property that >>> >>> one RUN line corresponds precisely to one command that's >>> executed. This is good for humans and will enable

Thanks, Galina. It doesn't explain why the test worked on some bots but not this one, but Justin's workaround is okay with me. --paulr From: Galina Kistanova [mailto:gkistanova at gmail.com] Sent: Thursday, November 09, 2017 10:09 AM To: Robinson, Paul Cc: Davide Italiano; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Problem with 'sed' on one Windows bot? There is nothing

On 10/12/2013 04:20, Sean Silva wrote: > The classic way to do this sort of checking is by hacking into the > tool that actually interprets it (i.e. lit in this case). Considering > that lit is Python, it should be pretty easy to insert an ad-hoc regex > check (or even something substantially more sophisticated). E.g. > insert code into TestRunner.py's

Hi, I am observing a deadlock with llvm-lit on windows 7. When I attached a debugger, the communicate() call is blocked. In file utils/lit/lit/TestRunner.py > # FIXME: There is probably still deadlock potential here. Yawn. > procData = [None] * len(procs) > procData[-1] = procs[-1].communicate() I am invoking python directly on windows to run the unit tests.

It looks like the bots are still red? — Adrian > On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at google.com> wrote: > > Wasn't quite fixed, but it got a lot further this time. This time there was still an issue in the test_debuginfo.pl <http://test_debuginfo.pl/> script regarding a hardcoded path to the llgdb.py script. I think I never encountered this locally

Hi all, As you may or may not have noticed, I have gradually been replacing the testing infrastructure in LLVM. Most of this work is moving LLVM and Clang to share a single testing tool, 'lit'. See: http://llvm.org/cmds/lit.html for documentation on the tool itself. If you haven't already tried it, please consider switch to 'make check-lit' as an alternative to 'make

Thank you. Alexei just committed the change to SVN. Regards, Marco Leogrande Sent by a carbon-based life form; hence, it may contain repetitions, inaccuracies, logical fallacies and repetitions. On Wed, Jun 17, 2015 at 2:52 PM, Galina Kistanova <gkistanova at gmail.com> wrote: > LGTM. > Please commit. > > Thanks > > Galina > > On Tue, Jun 16, 2015 at 8:32 PM,

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

Great! It's close to the end of the day, so I'll submit tomorrow to make sure everything has a chance to go fully green again to ensure I get failure emails if it breaks. On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com> wrote: > I can confirm that that fixes the issue! > > — adrian > > > On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner

Hi Zackary, Did you see my followup to you cfe-commits rollback: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171120/210212.html I think you can just remove the change to cfe/trunk/test/CMakeLists.txt and it should work just fine. hth... don On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just an update, > > At

I’ve had another look, and some of the failing tests don’t use temporary files, so I don’t think this is a case of tests having side-effects. Instead, I’ve noticed that in the build log (http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6552/steps/build-unified-tree/logs/stdio), llvm-tblgen.exe is built (my patch modified it), but the table-generation steps of the

IIUC you are mainly wanting to test LLD's PDB generation. Obviously a test suite plugged in under clang/test is not a good fit for that. It could arguably fit into the LLD project, but separating it out as a more end-to-end integration project a-la test-suite seems like a much better idea. Moving debuginfo-tests seems like a way to get a project in place with the right layering and maybe