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

Was this tested? I am not getting APPLE here:

$ uname -s
Darwin

I am going to land this, its cosmetics and the 9.0 branch was cut.

I did some more testing and from my point of view this seems to work. If it looks acceptable to you, I would like to land it tomorrow (CEST) before the 9.0 branch cut.

Thanks for taking a look.

Address Saleem's feedback

That's a fair point. However, changing the name of the parameter would force us to update quite a number of bot configurations, caches and documentation. So if it's "acceptable" I would be in favor to keep LLDB_USE_SYSTEM_DEBUGSERVER.
Also it's kind-of in line with the (internal) LLDB_CAN_USE_DEBUGSERVER and LLDB_CAN_USE_LLDB_SERVER variables.

Jonas is right, that there is nothing wrong with this code, but that it's just redundant as we'll do all of this in LLDBConfig anyway. Removing it means adding a potential difference for standalone builds, but in the end it should be fine.