Page MenuHomePhabricator
Feed Advanced Search

Fri, May 17

sgraenitz committed rGfd0779181f55: [CMake] Add first CMake cache files (authored by sgraenitz).
[CMake] Add first CMake cache files
Fri, May 17, 12:18 PM
sgraenitz committed rGdcc477e38cc4: [CMake] Inline info plist in lldb driver (authored by sgraenitz).
[CMake] Inline info plist in lldb driver
Fri, May 17, 12:18 PM
sgraenitz added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

Ok thanks. I will be OOO next week, so no hurries.

Fri, May 17, 12:09 PM · Restricted Project
sgraenitz added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

How does this cleanup affect dependency tracking? Does the build dir become unusable after running ninja install?

In D61952#1504942, @sgraenitz wrote:
Actually, why not make the copy operations PRE_BUILD actions of the test suite instead of POST_BUILD actions of their executables?

In D61952#1505019, @sgraenitz wrote:
The solution to the "install -> test" issue would be having both I guess.

Fri, May 17, 7:24 AM · Restricted Project
sgraenitz added a comment to D61956: [CMake] Add first CMake cache files.

I noticed you have lots of comments that say "Release has different values for these variables".

Fri, May 17, 3:50 AM · Restricted Project, Restricted Project
sgraenitz updated the diff for D61956: [CMake] Add first CMake cache files.

Fix default install locations and add comments on how to use DESTDIR

Fri, May 17, 3:15 AM · Restricted Project, Restricted Project
sgraenitz added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

Sure, ideally CMake defined a global install order and this order would handle overlap. I think that's unlikely to happen. It took quite some time to find and fix an overlap case downstream and I think it's worth avoiding it in general in the future. OTOH I see that the solution shouldn't be too intrusive. For the swift resources: I am not familiar with the details; all I know is that tests fail if they are missing.

Fri, May 17, 2:16 AM · Restricted Project

Thu, May 16

sgraenitz added inline comments to D61956: [CMake] Add first CMake cache files.
Thu, May 16, 10:57 AM · Restricted Project, Restricted Project
sgraenitz added inline comments to D61956: [CMake] Add first CMake cache files.
Thu, May 16, 10:52 AM · Restricted Project, Restricted Project
sgraenitz updated the diff for D61956: [CMake] Add first CMake cache files.

Add back CACHE STRING "" for CMAKE variables

Thu, May 16, 10:38 AM · Restricted Project, Restricted Project
sgraenitz added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

Yet another option: we could install the framework tools to a fake location and copy them to their final destination (overwriting their build-tree pendants) in a manual install step at the very end of the install process. The problem here is, that there may be more things in the build-tree framework than we overwrite, and thus remain in the install-tree (thinking about Swift resources in swift-lldb for example).

Thu, May 16, 10:22 AM · Restricted Project
sgraenitz added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

I thought about one more option, but I don't think it's better than the current proposal: instead of deleting the build-tree resources in the very first install step, I could install the framework manually at this point and skip its regular install target. We would loose implicit stripping and RPATH replacement for the dylib though. Should be possible to do it manually, but if it breaks, we won't notice. So, it's not quite appealing.

Thu, May 16, 10:10 AM · Restricted Project
sgraenitz added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

Actually, why not make the copy operations PRE_BUILD actions of the test suite instead of POST_BUILD actions of their executables?

Thu, May 16, 9:15 AM · Restricted Project
sgraenitz added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

I'm not very familiar with frameworks and complexities involved in creating them, but the fact that we need to delete stuff from the build tree in order to install properly makes me think that there is something fishy going on. Is there no way to arrange things so that this can be avoided?

Thu, May 16, 9:12 AM · Restricted Project
sgraenitz added a comment to D61956: [CMake] Add first CMake cache files.

Thanks for your input.

Thu, May 16, 7:09 AM · Restricted Project, Restricted Project
sgraenitz updated the diff for D61956: [CMake] Add first CMake cache files.

Rename macOS specific cache file.
Add settings and comments.
Fix install destinations by appending Developer and SharedFrameworks respectively.

Thu, May 16, 6:59 AM · Restricted Project, Restricted Project

Wed, May 15

sgraenitz created D61956: [CMake] Add first CMake cache files.
Wed, May 15, 11:04 AM · Restricted Project, Restricted Project
sgraenitz updated the summary of D61952: [CMake] Stabilize install process for LLDB.framework.
Wed, May 15, 10:43 AM · Restricted Project
sgraenitz created D61952: [CMake] Stabilize install process for LLDB.framework.
Wed, May 15, 9:32 AM · Restricted Project
sgraenitz added a comment to D61877: [CMake] Add error to clarify that lldb requires libcxx.

Yes, sorry for that. I realized it after the commit was in. The commit I got from arc patch did have the original author information. It must have changed in git llvm push, probably because it's still going to SVN and then gets mirrored back to git. I missed this last detail.

Wed, May 15, 5:13 AM · Restricted Project, Restricted Project
sgraenitz committed rGa5588c4583a7: [CMake] Add error to clarify that lldb requires libcxx (authored by sgraenitz).
[CMake] Add error to clarify that lldb requires libcxx
Wed, May 15, 1:57 AM

Tue, May 14

sgraenitz accepted D61877: [CMake] Add error to clarify that lldb requires libcxx.

Sure, will commit this on your behalf tomorrow. (If nothing else comes up.)

Tue, May 14, 9:55 AM · Restricted Project, Restricted Project
sgraenitz added a comment to D61877: [CMake] Add error to clarify that lldb requires libcxx.

LGTM

Tue, May 14, 8:38 AM · Restricted Project, Restricted Project
sgraenitz added a comment to D61877: [CMake] Add error to clarify that lldb requires libcxx.

Thanks for adding this. Would it make sense to use LLVM_ENABLE_PROJECTS_USED? https://github.com/llvm/llvm-project/blob/a568222d/llvm/CMakeLists.txt#L128

Tue, May 14, 2:50 AM · Restricted Project, Restricted Project

Mon, May 13

sgraenitz added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

It looks like this test is flaky [...] what would you say to just deleting the "# CHECK: 1 location added to breakpoint 1" line from the test?

Mon, May 13, 2:52 AM · Restricted Project, Restricted Project
sgraenitz committed rG7e8be135cf46: Fix flakiness in lldb lit test (authored by sgraenitz).
Fix flakiness in lldb lit test
Mon, May 13, 2:49 AM

Thu, May 9

sgraenitz committed rGf0ee69f75d61: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors (authored by sgraenitz).
[JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors
Thu, May 9, 9:39 AM
sgraenitz added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

I can update config.py to create the right features, but we can also use UNSUPPORTED: system-windows, so I'll look into the best way to do this.

Perfect, thanks

Thu, May 9, 9:38 AM · Restricted Project, Restricted Project
sgraenitz updated the diff for D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

Add back test requirement target-x86_64

Thu, May 9, 8:48 AM · Restricted Project, Restricted Project
sgraenitz added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

Sorry for the drive-by... what is this REQUIRES: nowindows? I don't see where lit generates this property. I grepped all of llvm-project.git and I see it used in two tests, but not where it's produced. Which suggests that those tests don't actually run *anywhere*.

Thu, May 9, 8:26 AM · Restricted Project, Restricted Project
sgraenitz updated the diff for D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.
  1. XFAIL: system-windows
Thu, May 9, 8:18 AM · Restricted Project, Restricted Project
sgraenitz added inline comments to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.
Thu, May 9, 8:18 AM · Restricted Project, Restricted Project
sgraenitz added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

@stella.stamenova Can you have a look at the lit test please? It works on macOS and Linux, but I didn't test Windows. Should I add something like # REQUIRES: nowindows or is it fine like this?

Thu, May 9, 7:42 AM · Restricted Project, Restricted Project
sgraenitz added a reviewer for D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors: stella.stamenova.
Thu, May 9, 7:36 AM · Restricted Project, Restricted Project
sgraenitz updated the diff for D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

Generalize lit test

Thu, May 9, 7:33 AM · Restricted Project, Restricted Project
sgraenitz abandoned D51546: [WIP] Fix parsing of OSO entries for LTO optimized compile units.
Thu, May 9, 2:37 AM · Restricted Project
sgraenitz abandoned D51744: [WIP] Early ThinLTOLayer2 prototype.
Thu, May 9, 2:37 AM · Restricted Project
sgraenitz abandoned D52375: [WIP] Support multiple compile units per OSO entry in SymbolFileDWARFDebugMap.
Thu, May 9, 2:35 AM
sgraenitz abandoned D61065: [JITLink] Pass ObjectFile in NotifyLoaded() for JITEventListener support.
Thu, May 9, 2:34 AM · Restricted Project
sgraenitz added a comment to D61065: [JITLink] Pass ObjectFile in NotifyLoaded() for JITEventListener support.

Ok, I went with MCJIT for now. Will leave this here for future reference.

Thu, May 9, 2:34 AM · Restricted Project
sgraenitz abandoned D51128: [ORC] LLJITTest: API test and usage examples with actual codegen.
Thu, May 9, 2:32 AM · Restricted Project
sgraenitz abandoned D51126: [ORC] LLJIT::Create() proposal: add flag to enable multithreaded codegen.
Thu, May 9, 2:32 AM · Restricted Project

Wed, May 8

sgraenitz added inline comments to D61438: [ASTImporter] Use llvm::Expected and Error in the importer API.
Wed, May 8, 10:59 AM · Restricted Project, Restricted Project, Restricted Project
sgraenitz added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

Thanks for your reply and thoughts about that.

Wed, May 8, 10:34 AM · Restricted Project, Restricted Project
sgraenitz updated the diff for D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

Add lit test

Wed, May 8, 10:12 AM · Restricted Project, Restricted Project

Mon, May 6

sgraenitz created D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.
Mon, May 6, 2:06 PM · Restricted Project, Restricted Project

Sat, May 4

sgraenitz added inline comments to D61438: [ASTImporter] Use llvm::Expected and Error in the importer API.
Sat, May 4, 6:50 AM · Restricted Project, Restricted Project, Restricted Project

Apr 25 2019

sgraenitz updated the diff for D61065: [JITLink] Pass ObjectFile in NotifyLoaded() for JITEventListener support.

For illustration: pass ownership to ObjectLinkingLayer and hand out a MemBufferRef in NotifyLoaded

Apr 25 2019, 3:28 AM · Restricted Project
sgraenitz added a comment to D61065: [JITLink] Pass ObjectFile in NotifyLoaded() for JITEventListener support.

Ok I see, as long as the original MemoryBuffer exists, we can recreate an identical ObjectFile on the client side. Currently it gets deleted together with JITLinkContext when returning from jitLink().

Apr 25 2019, 3:21 AM · Restricted Project

Apr 24 2019

sgraenitz added a comment to D58704: Initial (incomplete) implementation of JITLink - A replacement for RuntimeDyld..

Maybe not the most elegant solution, but this seems to work: https://reviews.llvm.org/D61065

Apr 24 2019, 6:31 AM · Restricted Project
sgraenitz created D61065: [JITLink] Pass ObjectFile in NotifyLoaded() for JITEventListener support.
Apr 24 2019, 6:29 AM · Restricted Project
sgraenitz added a comment to D58704: Initial (incomplete) implementation of JITLink - A replacement for RuntimeDyld..

One crucial part that I found missing here is a way to connect JITEventListener (like GDBJITRegistration, PerfJITEvents, etc.), because the new ObjectLinkingLayer::NotifyLoaded function only provides the module key but no ObjectFile so we cannot create and pass over a LoadedObjectInfo as with RuntimeDyld. Please see my inline comments for some pointers.

Apr 24 2019, 5:27 AM · Restricted Project

Apr 23 2019

sgraenitz accepted D59831: [CMake] macOS: Find DebugSymbols.framework inside the SDK.

LGTM too. Did this land?

Apr 23 2019, 5:02 AM · Restricted Project

Apr 18 2019

sgraenitz added a comment to D60863: [CMake] Emit LLDB.framework.dSYM to avoid potential name collision with driver's lldb.dSYM.

This was mostly to illustrate usage of the matching LLVM commit. Unlikely to break something. Post-commit review should be sufficient.

Apr 18 2019, 9:42 AM · Restricted Project
sgraenitz committed rG31d0ce005c80: [CMake] Emit LLDB.framework.dSYM to avoid potential name collision with… (authored by sgraenitz).
[CMake] Emit LLDB.framework.dSYM to avoid potential name collision with…
Apr 18 2019, 9:36 AM
sgraenitz committed rGab58268fdaf5: [CMake] Allow custom extensions for externalized debug info (authored by sgraenitz).
[CMake] Allow custom extensions for externalized debug info
Apr 18 2019, 9:36 AM
sgraenitz added a comment to D60862: [CMake] Allow custom extensions for externalized debug info.

Yes, scopes are per directory; macros operate on the caller's scope and functions add one.

Apr 18 2019, 9:21 AM · Restricted Project
sgraenitz added a comment to D60862: [CMake] Allow custom extensions for externalized debug info.

Actually, thinking more about this, how do you use it? LLVM_EXTERNALIZE_DEBUGINFO_EXTENSION is a global but this would be different per target.

Apr 18 2019, 8:49 AM · Restricted Project
sgraenitz added a comment to D60862: [CMake] Allow custom extensions for externalized debug info.

Enables https://reviews.llvm.org/D60863

Apr 18 2019, 4:28 AM · Restricted Project
sgraenitz created D60863: [CMake] Emit LLDB.framework.dSYM to avoid potential name collision with driver's lldb.dSYM.
Apr 18 2019, 4:28 AM · Restricted Project
sgraenitz created D60862: [CMake] Allow custom extensions for externalized debug info.
Apr 18 2019, 4:19 AM · Restricted Project

Apr 16 2019

sgraenitz added a comment to D60360: Dump the minimal version of cmake 3.5.0.

Ok, so far this appears to be a rare issue that we don't know much about. I think keeping LLVM and its subprojects in sync (which means CMake version 3.4.3) should be the prio for now.

Apr 16 2019, 5:49 AM · Restricted Project
sgraenitz added a comment to D60360: Dump the minimal version of cmake 3.5.0.

Can you please explain in more detail how this is supposed to fix the issue?

Apr 16 2019, 4:58 AM · Restricted Project

Apr 10 2019

sgraenitz added a comment to D60508: [NFC] Remove ASCII lines from comments.

+1 Following the local coding style was a pain when adding functions in these files. Good step forward.
This covers the majority of occurrences. Leaving unittests unchanged is probably intentional. There's a few more left in tools and other corners for a follow-up.

Apr 10 2019, 6:28 AM · Restricted Project

Apr 5 2019

sgraenitz accepted D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

you should be using the same sysroot to build LLVM and LLDB. In my specific problem, when you build any of the lldb tools (e.g. lldb-server) it fails to link because you are building the tool against the freshly built libc++ but the llvm libraries you had previously built were linked against the NDK's libc++.

Apr 5 2019, 12:14 PM · Restricted Project
sgraenitz added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

No, everything is being built for android. Cross-compiling lldb-server involves cross-compiling llvm libraries, clang libraries, and if you've got swift in the picture, swift host libraries. LLVM and clang libraries are built against the libc++ from the android NDK, but in standalone builds, LLDB will try to link against the freshly built libc++ from LLVM. You get loads of undefined references to symbols from the NDK's libc++.

Apr 5 2019, 8:17 AM · Restricted Project
sgraenitz added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

[LLVM_LIBRARY_DIR is] not a cache variable when it's an in-tree build

Apr 5 2019, 8:02 AM · Restricted Project

Apr 4 2019

sgraenitz added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

From the looks of it, clang needs to set it manually because they rely on llvm-config instead of using find_package.

Apr 4 2019, 3:09 AM · Restricted Project

Apr 3 2019

sgraenitz added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

Major concern from my side is that clang does something like this too:

clang/CMakeLists.txt
86:  set(LLVM_LIBRARY_DIR ${LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
125:  link_directories("${LLVM_LIBRARY_DIR}")
Apr 3 2019, 6:25 AM · Restricted Project

Mar 13 2019

sgraenitz added a comment to D58704: Initial (incomplete) implementation of JITLink - A replacement for RuntimeDyld..
Mar 13 2019, 1:50 PM · Restricted Project

Mar 12 2019

sgraenitz committed rG02e88490c1e0: Revert "[CMake] Avoid clang-tablegen-targets dependency when building sphinx… (authored by sgraenitz).
Revert "[CMake] Avoid clang-tablegen-targets dependency when building sphinx…
Mar 12 2019, 8:55 AM
sgraenitz added a reverting change for rG511066858d44: [CMake] Avoid clang-tablegen-targets dependency when building sphinx docs…: rG02e88490c1e0: Revert "[CMake] Avoid clang-tablegen-targets dependency when building sphinx….
Mar 12 2019, 8:55 AM

Mar 11 2019

sgraenitz created D59232: [CMake] Avoid clang-tablegen-targets dependency when building sphinx docs (experimental).
Mar 11 2019, 3:31 PM · Restricted Project

Feb 20 2019

sgraenitz accepted D58193: Do not explicitly depend on llvm tools during standalone build.

@serge-sans-paille After all, it appears to me that your issue is caused by something else, but if this change fixes it, I am not against taking it for now. It shouldn't do any harm. Please get in touch with @hans if this is really relevant for release_80.

Feb 20 2019, 10:29 AM · Restricted Project

Feb 19 2019

sgraenitz added a comment to D55653: [lldb-mi] Check raw pointers before passing them to std::string ctor/assignment.

Good initiative to fix potential nullptr assignments to std::string.

Feb 19 2019, 10:29 AM · Restricted Project

Feb 18 2019

sgraenitz added a comment to D58193: Do not explicitly depend on llvm tools during standalone build.

@sgraenitz I currently have this patch applied to LLVM 8rc1 source tree for fedora, because it wasn't working automagically otherwise. Reading the discussion, I don't think I missed some configuration stuff, or what did I miss when configuring the build of lldb in standalone mode?

Feb 18 2019, 12:03 PM · Restricted Project
sgraenitz added a reviewer for D58193: Do not explicitly depend on llvm tools during standalone build: mgorny.
Feb 18 2019, 11:45 AM · Restricted Project
sgraenitz added a comment to D58193: Do not explicitly depend on llvm tools during standalone build.

Yap, will try and come up with a proposal soon.

Feb 18 2019, 4:37 AM · Restricted Project

Feb 15 2019

sgraenitz committed rG42a9da7b3550: Fix potential UB when target_file directory is null (authored by sgraenitz).
Fix potential UB when target_file directory is null
Feb 15 2019, 8:42 AM
sgraenitz added a comment to D58193: Do not explicitly depend on llvm tools during standalone build.

BTW, what's the reason for having super-high-fidelity list of dependencies in a standalone build?

Feb 15 2019, 7:14 AM · Restricted Project

Feb 14 2019

sgraenitz added a comment to D57402: build: remove custom variables.

I don't want to play the nitpicker here, but did you test this? If so, please provide a sample configuration command line.

Feb 14 2019, 10:40 AM · Restricted Project
sgraenitz added a comment to D58193: Do not explicitly depend on llvm tools during standalone build.

@xiaobai && @compnerd Do you know if find_package can tell us anything about it?

Feb 14 2019, 10:17 AM · Restricted Project
sgraenitz added a comment to D58193: Do not explicitly depend on llvm tools during standalone build.

All these targets are exported from the LLVM build-tree since D56606 and from the install-tree since D57383.

Feb 14 2019, 10:16 AM · Restricted Project
sgraenitz updated subscribers of D58193: Do not explicitly depend on llvm tools during standalone build.
Feb 14 2019, 10:16 AM · Restricted Project
sgraenitz added a comment to D57964: Fix potential UB when target_file directory is null.

Ping

Feb 14 2019, 10:05 AM · Restricted Project
sgraenitz committed rGdb85fdd11595: [CMake] Fix RPATH handling for LLDB.framework (authored by sgraenitz).
[CMake] Fix RPATH handling for LLDB.framework
Feb 14 2019, 9:36 AM
sgraenitz closed D57989: [CMake] Fix RPATH handling for LLDB.framework.
Feb 14 2019, 9:36 AM · Restricted Project

Feb 13 2019

sgraenitz added a comment to D57989: [CMake] Fix RPATH handling for LLDB.framework.

we are also doing a CMake version check in LLDBConfig for the same purpose. Seems like you could consolidate those?

Feb 13 2019, 5:53 AM · Restricted Project
sgraenitz updated the diff for D57989: [CMake] Fix RPATH handling for LLDB.framework.

Submit proposal from Diff 186517

Feb 13 2019, 5:44 AM · Restricted Project
sgraenitz retitled D57989: [CMake] Fix RPATH handling for LLDB.framework from Convert genexp that used an actual string instead of the genexp to [CMake] Fix RPATH handling for LLDB.framework.
Feb 13 2019, 5:44 AM · Restricted Project
sgraenitz commandeered D57989: [CMake] Fix RPATH handling for LLDB.framework.
Feb 13 2019, 5:44 AM · Restricted Project

Feb 12 2019

sgraenitz added a comment to D57989: [CMake] Fix RPATH handling for LLDB.framework.

Looking at the code more closely, it turns out this is not the only issue:

Feb 12 2019, 11:07 AM · Restricted Project
sgraenitz added a comment to D57989: [CMake] Fix RPATH handling for LLDB.framework.

Tested it for the lldb driver and you are right, that the genex ends up in the binary -- interesting. I then also tested with your change, but it gave me the same:

Load command 17
          cmd LC_RPATH
      cmdsize 40
         path $<TARGET_FILE:liblldb> (offset 12)
Feb 12 2019, 6:57 AM · Restricted Project
sgraenitz added a comment to D57989: [CMake] Fix RPATH handling for LLDB.framework.

A chunk of code referred to a generator expression wrapped in quotations and then referred to later again in quotations which caused cmake to think it was something to be referred to as a string.

Feb 12 2019, 5:28 AM · Restricted Project
sgraenitz requested changes to D57402: build: remove custom variables.

Actually, both use cases already work without this change: passing LLVM_DIR && Clang_DIR or passing LLDB_PATH_TO_LLVM_BUILD. IMHO this patch needs good reason to land.

Feb 12 2019, 5:13 AM · Restricted Project
sgraenitz added a comment to D58109: [llvm] [cmake] Provide split include paths in LLVMConfig.

Can't speak for all the subproject, but with D57995 this should work for LLDB.

Feb 12 2019, 3:51 AM · Restricted Project
sgraenitz added a comment to D57995: [lldb] [cmake] Use install directories for LLVM_* variables.

Indeed it is a problem. However, it seems to be a bug that LLVM_INCLUDE_DIR contains two directories.

Feb 12 2019, 3:28 AM · Restricted Project, Restricted Project

Feb 11 2019

sgraenitz added inline comments to D56531: [CMake] Replace use of llvm-config with LLVM and Clang CMake packages.
Feb 11 2019, 12:25 PM · Restricted Project
sgraenitz added a comment to D57995: [lldb] [cmake] Use install directories for LLVM_* variables.

Indeed, these variables do not exist when running against a LLVM/Clang install-tree and this should be fixed. Did you give this a try running against a LLVM/Clang build-tree? Dumping the values here locally, gives me:

LLVM_BUILD_MAIN_INCLUDE_DIR /path/to/llvm/include
LLVM_BUILD_LIBRARY_DIR      /path/to/llvm-build/./lib
LLVM_BUILD_BINARY_DIR       /path/to/llvm-build
Feb 11 2019, 12:19 PM · Restricted Project, Restricted Project
sgraenitz updated the diff for D57964: Fix potential UB when target_file directory is null.

Polish && error out also on empty string

Feb 11 2019, 3:44 AM · Restricted Project