All of the code in the LLDB project is available under the
`"Apache 2.0 License with LLVM exceptions"`_.
-.. _"Apache 2.0 License with LLVM exceptions": http://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
+.. _"Apache 2.0 License with LLVM exceptions": https://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
Why a New Debugger?
-------------------
:maxdepth: 1
:caption: External Links
- Source Code <http://llvm.org/viewvc/llvm-project/lldb/trunk/>
+ Source Code <https://llvm.org/viewvc/llvm-project/lldb/trunk/>
Code Reviews <https://reviews.llvm.org>
Bug Reports <https://bugs.llvm.org/>
this tight integration the Getting Started guides for both of these projects
come as prerequisite reading:
-* `LLVM <http://llvm.org/docs/GettingStarted.html>`_
+* `LLVM <https://llvm.org/docs/GettingStarted.html>`_
* `Clang <http://clang.llvm.org/get_started.html>`_
The following requirements are shared on all platforms.
project, it generates the files needed by your build tool. The recommended
build tool for LLVM is Ninja, but other generators like Xcode or Visual Studio
may be used as well. Please also read `Building LLVM with CMake
-<http://llvm.org/docs/CMake.html>`_.
+<https://llvm.org/docs/CMake.html>`_.
Regular in-tree builds
**********************
CMake caches allow to store common sets of configuration options in the form of
CMake scripts and can be useful to reproduce builds for particular use-cases
-(see by analogy `usage in LLVM and Clang <http://llvm.org/docs/AdvancedBuilds.html>`_).
+(see by analogy `usage in LLVM and Clang <https://llvm.org/docs/AdvancedBuilds.html>`_).
A cache is passed to CMake with the ``-C`` flag, following the absolute path to
the file on disk. Subsequent ``-D`` options are still allowed. Please find the
currently available caches in the `lldb/cmake/caches/
Build, test and install a distribution of LLDB from the `monorepo
<https://github.com/llvm/llvm-project>`_ (see also `Building a Distribution of
-LLVM <http://llvm.org/docs/BuildingADistribution.html>`_):
+LLVM <https://llvm.org/docs/BuildingADistribution.html>`_):
::
===================
Refer to the `LLVM Getting Started Guide
-<http://llvm.org/docs/GettingStarted.html#getting-started-with-llvm>`_
+<https://llvm.org/docs/GettingStarted.html#getting-started-with-llvm>`_
for general instructions on how to check out source. Note that LLDB
depends on having a working checkout of LLVM and Clang, so the first
step is to download and build as described at the above URL. The same
--------------------
Please refer to the `LLVM Developer Policy
-<http://llvm.org/docs/DeveloperPolicy.html>`_ for information about
+<https://llvm.org/docs/DeveloperPolicy.html>`_ for information about
authoring and uploading a patch. LLDB differs from the LLVM Developer
Policy in the following respects.
* Invalid input. To deal with invalid input, such as malformed DWARF,
missing object files, or otherwise inconsistent debug info, LLVM's
error handling types such as `llvm::Expected<T>
- <http://llvm.org/doxygen/classllvm_1_1Expected.html>`_ or
+ <https://llvm.org/doxygen/classllvm_1_1Expected.html>`_ or
`llvm::Optional<T>
- <http://llvm.org/doxygen/classllvm_1_1Optional.html>`_ should be
+ <https://llvm.org/doxygen/classllvm_1_1Optional.html>`_ should be
used. Functions that may fail should return their result using these
wrapper types instead of using a bool to indicate success. Returning
a default value when an error occurred is also discouraged.
* Fatal errors. Aborting LLDB's process using
`llvm::report_fatal_error()` or `abort()` should be avoided at all
costs. It's acceptable to use `llvm_unreachable()
- <http://llvm.org/doxygen/Support_2ErrorHandling_8h.html>`_ for
+ <https://llvm.org/doxygen/Support_2ErrorHandling_8h.html>`_ for
actually unreachable code such as the default in an otherwise
exhaustive switch statement.