Achieve the same via extra HINT to find_package(Clang ...)
Thu, Aug 8
So, why doesn't LLVM_ENABLE_WERROR suffice? It looks like that ought to work even in standalone builds...
Wed, Aug 7
Originally introduced with D31969. LGTM. Maybe we can remove even more?
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.
Tue, Aug 6
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
Fri, Aug 2
Is there a way to use the debugserver in the framework instead?
Thu, Aug 1
> xcodebuild -configuration Release -target debugserver > codesign -dv Release/bin/LLDB.framework/Versions/A/Resources/debugserver > codesign -dv Release/bin/debugserver
Wed, Jul 31
Tue, Jul 30
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
Mon, Jul 29
Thanks for your feedback.
Sat, Jul 27
Feedback and polishing; latest rendered output here: http://tiny.cc/i5ncaz
Hi Greg, thanks for your feedback.
Address recent feedback
Fri, Jul 26
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.
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
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
Thu, Jul 25
Wed, Jul 24
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
Jul 23 2019
[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
Jul 22 2019
Jul 20 2019
Jul 19 2019
Was this tested? I am not getting APPLE here:
$ uname -s Darwin
Jul 18 2019
I am going to land this, its cosmetics and the 9.0 branch was cut.
Jul 17 2019
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.