Right, this was a missing deprecation change. Thanks for posting! Lang fixed it the same day, so I guess we can abandon this review.

This change was proposed in review D65934

Did this land?

Achieve the same via extra HINT to find_package(Clang ...)

In D65939#1620780, @labath wrote:

So, why doesn't LLVM_ENABLE_WERROR suffice? It looks like that ought to work even in standalone builds...

Right

Originally introduced with D31969. LGTM. Maybe we can remove even more?

In D65798#1618609, @labath wrote:

Making it so that the clang is automatically found it if happens to be next to llvm seems like a reasonable thing to me. I have no idea what would be the canonical cmake way to do that...

Update documentation to mention multiple provided build trees and the usage of Clang_DIR

What do you think?

Change comment and condition to only infer Clang_DIR if it exists.

Solutions are clearly favorable over workarounds like this, but I couldn't find one. Xcode has a mechanism called sign on copy which seems to be the native way to avoid this problem, but I couldn't get it to work with LLDB, because I want to copy the build output of a target and this caused a cyclic dependency. I didn't find more information about it and there seems to be no way to generate this behavior with CMake. The only way around seems to be a custom script, but that is no better than the workaround here.

Improve warning message

In D65566#1611007, @JDevlieghere wrote:

Is there a way to use the debugserver in the framework instead?

Checked with:

> xcodebuild -configuration Release -target debugserver
> codesign -dv Release/bin/LLDB.framework/Versions/A/Resources/debugserver
> codesign -dv Release/bin/debugserver

In D65438#1608900, @thakis wrote:

This broke the sphinx bot

This was fixed quite some time ago.

Yes, agree! Hopefully we will move on to a newer version (3.9?) some time soon, but that needs a broader discussion first.

If we want to add git at all, we should probably mention it somewhere else. I'm not sure where that would be - I suppose somewhere where it makes sense to worry about the minimum version, e.g. where the git-llvm script is concerned.

Undo Compiling -> Working with

Remove lldb documentation updates I just added accidentally

Move git version comment into a footnote in git-llvm section

Hi Lang, I am getting these warnings from ninja docs-llvm-html:

@clayborg I added a direct link to Xcode project generation here. Is that fine?

Add lld note to Windows section

Thanks for your feedback.

Feedback and polishing; latest rendered output here: http://tiny.cc/i5ncaz

Hi Greg, thanks for your feedback.

Address recent feedback

In D65330#1602786, @jryans wrote:

On http://releases.llvm.org/, for some recent versions like 8.0.0, the "Documentation" column has separate versioned links for "llvm clang lld clang-extra libc++ polly", but lldb doesn't appear there.

In D65330#1602756, @jryans wrote:

Hmm, are there the LLDB docs archived per release? [...] LLDB doesn't seem to appear in sub-project list of versioned docs

I added a few links to LLVM documentation here and wondered what to do with them, if this gets cherry-picked to release/9.x, e.g. https://llvm.org/docs/CMake.html
Ideally they would point to their 9.x counterparts, e.g. https://releases.llvm.org/9.0.0/docs/CMake.html and with 9.0.1 it should become https://releases.llvm.org/9.0.1/docs/CMake.html
Is there a way to do this in Sphinx?

Since Visual Studio is the only section in Building LLDB with CMake and Other Generators now, ...

Yes, this sounds like a good plan.

Merge Visual Studio build instructions into Common CMake options > Windows

Polishing

Since Visual Studio is the only section in Building LLDB with CMake and Other Generators now, I would like to:

Updated rendered HTML: http://weliveindetail.github.io/blog/res/lldb-docs/resources/build.html

Polish section CMake caches

Polish section Standalone builds

Add links to sections

View rendered HTML output here: http://weliveindetail.github.io/blog/res/lldb-docs/resources/build.html

LGTM

Interesting way to get from version to list! :)

We discussed this and came to an agreement only a few hours before in the team meeting

[lldb] Remove Xcode project legacy: https://reviews.llvm.org/D65155

Can we just use the mono-repo style build and use "cmake -G Xcode"?

Seriously, discussion for changes like this should be open for more than 1h15min! I am in favor of the change in principle, but there's a number of things that have been rushed over here, e.g.:

cmake/XcodeHeaderGenerator/CMakeLists.txt
scripts/finish-swig-wrapper-classes.sh
scripts/Xcode/build-llvm.py
scripts/Xcode/lldbbuild.py
scripts/Xcode/package-clang-resource-headers.py
scripts/Xcode/prepare-gtest-run-dir.sh
scripts/Xcode/repo.py
scripts/Xcode/repos/FALLBACK
scripts/Xcode/repos/svn-trunk.json