similar to: PSA: debuginfo-tests workflow changing slightly

llvm-profdata is part of llvm though. It’s perfectly fine for something in clang to depend on something in llvm. However, clang and lld are two independent llvm subprojects, neither of which can depend on each other. Generally speaking, from a layering perspective, if A depends on B and C, but B and C are independent, that should be reflected in the structure. For example, in CMake we will need

From the CI side moving this stuff around is a huge undertaking. We include this repo in every build, they will all need to be fixed and verified. It is a lot of work on our side. Is there a plan for both system to work side-by-side as we migrate jobs? Talking to Mike today, we estimated a week of work to migrate and verify, plus residual failures for the next month. Regarding your

On Fri, Nov 3, 2017 at 9:34 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > By adding in a different suite, you mean the lld part? I mean > theoretically, but that would be pretty awkward, because the idea behind > the lld requirement is that we want to make debuginfo-tests work with > clang-cl and CodeView debug info, and for this lld is a hard

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

> I'm honestly not opposed to this idea. It just seems a shame to do this for purely logistical reasons if most people agree that the "right" place for debuginfo-tests is outside of the clang tree. I totally understand what you are saying here and will just add that sometimes being part of a larger community means being willing to do things, sometimes, not exactly the “right”

Thank you Zach. > On Nov 6, 2017, at 13:37, Zachary Turner <zturner at google.com> wrote: > > I’m going to spend a little time seeing if i can make the change invisible to the bots so they will continue to work as they do today. Will report back after I’ve explored that a bit > On Mon, Nov 6, 2017 at 1:35 PM Mike Edwards <medwards at apple.com <mailto:medwards at

Hi all, I think I've addressed all the concerns here, and I believe there should be no immediate impact to the current workflow. with that said, I plan to commit this either later today or early tomorrow if there are no other concerns. On Tue, Nov 7, 2017 at 12:19 PM Zachary Turner <zturner at google.com> wrote: > I tested this out, and AFAICT nothing will change. It will continue

Since it's towards the end of the day already, I'll put this in tomorrow morning around 9 or 10, to make sure I'm around to fix anything that arises (or revert). On Thu, Nov 9, 2017 at 2:53 PM Mike Edwards <medwards at apple.com> wrote: > Hi Zach, > Thanks for doing this extra work to make this lower impact for the rest of > us. Let’s give it a try and see what

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: > >

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

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

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >

I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig into it once I get a chance -- traveling so, my access is a bit sketchy right now. I'll see if I can grab the logs and let you know if I find anything interesting. On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com> wrote: > That change was added specifically to workaround a failure

cmake -G Ninja -DLLVM_ENABLE_PROJECTS="debuginfo-tests" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -Wno-dev ../llvm &> ../../cmake.log in cmake.log -- Targeting X86 CMake Error at /home/nnelson/Documents/llvm-project/debuginfo-tests/CMakeLists.txt:30 (message):   Cannot run debuginfo-tests without python 3 installed python3

Hi Zachary: I was able to reproduce the greendragon results locally (OSX), and fix the problem by excluding 'debuginfo-tests' from check-clang -- this prevents them from being added twice, once for check-clang and again for check-debuginfo. Below are the minimized patches I used to reproduce and fix the problem -- based on your originals. I've verified these patches work when