Summary: This is currently hidden in the Host CMakeLists but we should also use this macro in other parts of LLDB where we have ObjC++ sources (see D74891)
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75164
Summary:
This is another attempt of 0bb90628b5.
The difference is that g_python_home is not declared as const. Since
some versions of python do not expect that.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74998
Summary:
This change allows a hard coded relative PYTHONHOME setting. So that
python can easily be packaged together with lldb.
The change includes:
1. Extend LLDB_RELOCATABLE_PYTHON to all platforms. It defaults to ON
for platforms other than Windows, to keep the behavior compatible.
2. Allows to customize LLDB_PYTHON_HOME. But still defaults to
PYTHON_HOME.
3. LLDB_PYTHON_HOME can be a path relative to liblldb. If it is
relative, we will resolve it before send it to Py_DecodeLocale.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74727
Summary:
The purpose of this patch is to make identifying missing dependencies clearer to the user.
`find_package` will report if a package is not found, that output, combined with the exiting
status message, is clearer than not having the additional verbosity.
If the SWIG dependency is required {LLDB_ENABLE_PYTHON, LLDB_ENABLE_LUA}
and SWIG is not available, fail the configuration step. Terminate the
configure early rather than later with a clear error message.
We could possibly modify:
`llvm-project/lldb/cmake/modules/FindPythonInterpAndLibs.cmake`
However, the patch here seems clear in my opinion.
Reviewers: aadsm, hhb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: labath, jrm, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74917
Summary:
The only use of this class was to implement the SharedCluster of ValueObjects.
However, the same functionality can be implemented using a regular
std::shared_ptr, and its little-known "sub-object pointer" feature, where the
pointer can point to one thing, but actually delete something else when it goes
out of scope.
This patch reimplements SharedCluster using this feature --
SharedClusterPointer::GetObject now returns a std::shared_pointer which points
to the ValueObject, but actually owns the whole cluster. The only change I
needed to make here is that now the SharedCluster object needs to be created
before the root ValueObject. This means that all private ValueObject
constructors get a ClusterManager argument, and their static Create functions do
the create-a-manager-and-pass-it-to-value-object dance.
Reviewers: teemperor, JDevlieghere, jingham
Subscribers: mgorny, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74153
Summary:
In D66791 I've introduced this [[ https://cmake.org/cmake/help/latest/module/CMakeDependentOption.html | `CMakeDependentOption` ]] but in
D71306 @JDevlieghere has changed the way optional dependencies
are handled in LLDB. Today there's no occurence of
`cmake_dependent_option` inside the lldb source tree.
That's why this include can be removed.
Reviewers: JDevlieghere, labath
Reviewed By: labath
Subscribers: labath, mgorny, lldb-commits, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74160
Just like Python, Lua should only be auto-enabled if SWIG is found as
well. This moves the logic of finding SWIG and Lua as a whole into a new
CMake package.
Libxml2 is already an optional dependency. It should use the same
infrastructure as the other dependencies.
Differential revision: https://reviews.llvm.org/D72290
As correctly pointed out by Martin on the mailing list, Python should
only be auto-enabled if SWIG is found as well. This moves the logic of
finding SWIG into FindPythonInterpAndLibs to make that possible.
To make diagnosing easier I've included a status message to convey why
Python support is disabled.
My earlier change for Python auto-detection caused PYTHON_HOME to be set
unconditionally, while before the change this only happened for Windows.
This caused the PythonDataObjectsTest to fail with an import error.
Python was the last remaining "optional" dependency for LLDB. This moves
the code to find Python into FindPythonInterpAndLibs using the same
principles as FindCursesAndPanel.
Differential revision: https://reviews.llvm.org/D72107
Use a status message to convey whether an optional dependency was found
or not. With the auto-detection code it's not longer as simple as
checking the CMake cache.
The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by
find_package_handle_standard_args. However this isn't valid for the
package name.
The argument for FOUND_VAR is "libedit_FOUND", but only "LibEdit_FOUND" and
"LIBEDIT_FOUND" are valid names.
This fixes all the variables set by FindLibEdit to match the desired
naming scheme.
PYTHON_LIBRARIES is the canonical variable set by FindPythonLibs while
PYTHON_LIBRARY is an implementation detail. This replaces the uses of
the latter with the former.
Because this is a macro, previous values of `find_package` persist
between calls. This means that if it is set to TRUE on any run, all
subsequent runs will have find_package set to TRUE regardles of whether
or not they should be.
The behaviour of `PYTHON_HOME` can be emulated by setting
`Python3_EXECUTABLE` to the absolute path instead of the custom variable
now that we can find the python interpreter.
Require a newer CMake on Windows to use the Python3 support that is
packaged in CMake. This version is able to check both 32-bit and 64-bit
versions and will setup everything properly without the user needing to
specify PYTHON_HOME. This enables building lldb's python bindings on
Windows under Azure's CI again.
> A macro is executed as if the macro body were pasted in place of the
> calling statement. This has the consequence that a return() in a macro
> body does not just terminate execution of the macro
After converting from a function() to a macro(), the return() became
invalid. This modifies the control flow to elude the return.
Recently there has been some discussion about how we deal with optional
dependencies in LLDB. The approach in LLVM is to make things work out of
the box. If the dependency isn't there, we move on silently.
That's not true for LLDB. Unless you explicitly disable the dependency
with LLDB_ENABLE_*, you'll get a configuration-time error. The
historical reason for this is that LLDB's dependencies have a much
broader impact, think about Python for example which is required to run
the test suite.
The current approach can be frustrating from a user experience
perspective. Sometimes you just want to ensure LLDB builds with a change
in clang.
This patch changes the optional dependencies (with the exception of
Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On,
Off or Auto, with the latter being the default. On and Off behave the
same as today, forcing the dependency to be enabled or disabled. If the
dependency is set to On but is not found, it results in a configuration
time warning. For Auto we detect if the dependency is there and either
enable or disable it depending on whether it's found.
Differential revision: https://reviews.llvm.org/D71306
PS: The reason Python isn't included yet is because it's so pervasive
that I plan on doing that in a separate patch.
Recently there has been some discussion about how we deal with optional
dependencies in LLDB. The approach in LLVM is to make things work out of
the box. If the dependency isn't there, we move on silently.
That's not true for LLDB. Unless you explicitly disable the dependency
with LLDB_ENABLE_*, you'll get a configuration-time error. The
historical reason for this is that LLDB's dependencies have a much
broader impact, think about Python for example which is required to run
the test suite.
The current approach can be frustrating from a user experience
perspective. Sometimes you just want to ensure LLDB builds with a change
in clang.
This patch changes the optional dependencies (with the exception of
Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On,
Off or Auto, with the latter being the default. On and Off behave the
same as today, forcing the dependency to be enabled or disabled. If the
dependency is set to On but is not found, it results in a configuration
time warning. For Auto we detect if the dependency is there and either
enable or disable it depending on whether it's found.
Differential revision: https://reviews.llvm.org/D71306
PS: The reason Python isn't included yet is because it's so pervasive
that I plan on doing that in a separate patch.
This implements a very elementary Lua script interpreter. It supports
running a single command as well as running interactively. It uses
editline if available. It's still missing a bunch of stuff though. Some
things that I intentionally ingored for now are that I/O isn't properly
hooked up (so every print goes to stdout) and the non-editline support
which is not handling a bunch of corner cases. The latter is a matter of
reusing existing code in the Python interpreter.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71234
At least one lldb bot still uses this cmake variable instead of
LLDB_ENABLE_CURSES. Add code to set the default value of the "enable"
variable based on the old value of the "disable" setting.
This should bring those bots back up, until we can update the master to
use the new setting.
This renames LLDB_CONFIG_TERMIOS_SUPPORTED to LLDB_ENABLE_TERMIOS. It
now also uses cmakedefine01 to keep things consistent with out other
optional dependencies. But more importantly it won't silently fail when
you forget to include Config.h.
Centralize the logic to determine what libraries to link against for
curses in the CMake file where it is actually being used. Use
target_include_directories instead of include_directories.
As suggested by Pavel in a code review:
> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..
Differential revision: https://reviews.llvm.org/D71280
We're checking for support but we're discarding the result. My best
guess is that these warnings were disabled in the past. However, I don't
see a reason to keep it that way.
This fixes the following warning for developers:
Target 'liblldb' was changed to a FRAMEWORK sometime after install(). This
may result in the wrong install DESTINATION. Set the FRAMEWORK property
earlier.
The solution is to pass the FRAMEWORK flag to add_lldb_library and set
the target property before install(). For now liblldb is the only
customer.
Centralize the logic to remove debugserver from
LLVM_DISTRIBUTION_COMPONENTS when LLDB_USE_SYSTEM_DEBUGSERVER is
enabled. Now this happens regardless of whether the tests are enabled.
Summary:
I want to be able to specify which python framework to use for lldb in macos. With python2.7 we could just rely on the MacOS one but python3.7 is not shipped with the OS.
An alternative is to use the one shipped with Xcode but that could be path dependent or maybe the user doesn't have Xcode installed at all.
A definite solution is to just ship a python framework with lldb. To make this possible I added "@loader_path/../../../" to the rpath so it points to the same directory as the LLDB.framework, this way we can just drop any frameworks there.
Reviewers: hhb, sgraenitz, xiaobai, smeenai, beanz, labath
Reviewed By: labath
Subscribers: beanz, labath, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69931
The swift build system has support for cross-compiling, installing, and
generating symbols for lldb. As the swift symbol-generation step occurs
after installation, we need to disable stripping during the install.
As the name suggests, the LLDB test dependencies only matter to the
different test suites. Therefore they belong in test/CMakeLists.txt
rather than the top-level CMakeLists.txt.
Make it possible to pass a build and install RPATH to
add_lldb_executable instead of having to call lldb_setup_rpaths after
the fact.
This fixes a real issue where setting an install RPATH with
lldb_setup_rpaths would only affect the symroot installation component.
Given that lldb_setup_rpaths sets a target property I would expect this
to be orthogonal to installation components. Regardless, it makes sense
to integrate this functionality in add_lldb_exectable.
llvm-svn: 375068
Summary: find_python_libs_windows might set LLDB_DISABLE_PYTHON to ON.
Unfortunately we do not re-check this variable before using variables filled in
by find_python_libs_windows, leading to a failed configuration.
llvm-svn: 374100
I often use `ninja lldb-test-deps` to build all the test dependencies
before running a subset of the tests with `lit --filter`. This
functionality seems to break relatively often because test dependencies
are tracked in an ad-hoc way acrooss cmake files. This patch adds a
helper function `add_lldb_test_dependency` to unify test dependency
tracking by adding dependencies to lldb-test-deps.
Differential revision: https://reviews.llvm.org/D68612
llvm-svn: 373996
Raphael Isemann