Add an option to skip generating a dSYM when installing the LLDB framework on Darwin.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D103124
Bump the required SWIG version to 3. If my memory serves me well we last
bumped the required SWIG version to 2 for Python 3. At that time SWIG 3
had already been around for a while so everyone I know was already using
that.
It appears that SWIG 3 is the only version that officially supports
C++11 which we're using in the typemap. SWIG 3 was released in 2014 so I
think it's reasonable to make that the minimum required version.
https://bugs.llvm.org/show_bug.cgi?id=48685
Differential revision: https://reviews.llvm.org/D94244
Raise awareness of the fact that some versions of swig and python (and
build types) just don't mix.
One day this will be a reason to require swig>=4.0, but this version is
too hot off the press right now..
Differential Revision: https://reviews.llvm.org/D88967
ptsname is not thread-safe. ptsname_r is available on most (but not all)
systems -- use it preferentially.
In the patch I also improve the thread-safety of the ptsname fallback
path by wrapping it in a mutex. This should guarantee the safety of a
typical ptsname implementation using a single static buffer, as long as
all callers go through this function.
I also remove the error arguments, as the only way this function can
fail is if the "primary" fd is not valid. This is a programmer error as
this requirement is documented, and all callers ensure that is the case.
Differential Revision: https://reviews.llvm.org/D88728
When doing a standalone build (i.e., building just LLDB against an existing
LLVM/Clang installation), LLDB is currently unable to find any Clang resource
directory that contains all the builtin headers we need to parse real source
code. This causes several tests that actually parse source code on disk within
the expression parser to fail (most notably nearly all the import-std-module
tests).
The reason why LLDB can't find the resource directory is that we search based on
the path of the LLDB shared library path. We assumed that the Clang resource
directory is in the same prefix and has the same relative path to the LLDB
shared library (e.g., `../clang/10.0.0/include`). However for a standalone build
where the existing Clang can be anywhere on the disk, so we can't just rely on
the hardcoded relative paths to the LLDB shared library.
It seems we can either solve this by copying the resource directory to the LLDB
installation, symlinking it there or we pass the path to the Clang installation
to the code that is trying to find the resource directory. When building the
LLDB framework we currently copy the resource directory over to the framework
folder (this is why the import-std-module are not failing on the Green Dragon
standalone bot).
This patch symlinks the resource directory of Clang into the LLDB build
directory. The reason for that is simply that this is only needed when running
LLDB from the build directory. Once LLDB and Clang/LLVM are installed the
already existing logic can find the Clang resource directory by searching
relative to the LLDB shared library.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D88581
Use the append_if CMake function from HandleLLVMOptions. Since we
include this file in LLDBStandalone it should work in both for in-tree
and out-of-tree builds.
This patch is a big sed to rename the following variables:
s/PYTHON_LIBRARIES/Python3_LIBRARIES/g
s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g
s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g
s/PYTHON_RPATH/Python3_RPATH/g
I've also renamed the CMake module to better express its purpose and for
consistency with FindLuaAndSwig.
Differential revision: https://reviews.llvm.org/D85976
This removes the fallback to Python 2 and makes Python 3 the only
supported configuration. This is the first step to fully migrate to
Python 3 over the coming releases as discussed on the mailing list.
http://lists.llvm.org/pipermail/lldb-dev/2020-August/016388.html
As a reminder, for the current release the test suite and the generated
bindings should remain compatible with Python 2.
Differential revision: https://reviews.llvm.org/D85942
This patch configures LLDB.framework to build as a flat unversioned
framework on non-macOS Darwin targets, which have never supported the
macOS framework layout.
This patch also renames the 'IOS' cmake variable to 'APPLE_EMBEDDED' to
reflect the fact that lldb is built for several different kinds of embedded
Darwin targets, not just iOS.
Differential Revision: https://reviews.llvm.org/D85770
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This quietly disabled use of zlib on Windows even when building with
-DLLVM_ENABLE_ZLIB=FORCE_ON.
> Rather than handling zlib handling manually, use find_package from CMake
> to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
> HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
> set to YES, which requires the distributor to explicitly select whether
> zlib is enabled or not. This simplifies the CMake handling and usage in
> the rest of the tooling.
>
> This is a reland of abb0075 with all followup changes and fixes that
> should address issues that were reported in PR44780.
>
> Differential Revision: https://reviews.llvm.org/D79219
This reverts commit 10b1b4a231 and follow-ups
64d99cc6ab and
f9fec0447e.
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
In addition to having the default fallback from Python 3 to Python 2, it
should also be possible to build against Python 2 explicitly. This patch
makes that possible by setting LLDB_PYTHON_VERSION. The variable only
has effect with CMake 3.12 or later.
Differential revision: https://reviews.llvm.org/D81501
Summary:
Long long ago system_libs was appended to LLDB_SYSTEM_LIBS in
cmake/LLDBDependencies.cmake. After that file was removed, system_libs
is orphaned.
Currently the only user is source/Utility. Move the logic there and
remove system_libs.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80253
Summary:
This changes allows to disable or use customized libxml2 for lldb.
1. Removes redundant include_directories. The one in LLDBConfig.cmake should be enough.
2. Link to ${LIBXML2_LIBRARIES} if xml2 is enabled.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80257
The install name for the Python 3 framework in Xcode is relative to
the framework's location and not the dylib itself.
@rpath/Python3.framework/Versions/3.x/Python3
This means that we need to compute the path to the Python3.framework
and use that as the RPATH instead of the usual dylib's directory.
Summary:
Previously the value of Python3_ROOT_DIR was set to the string
"PYTHON_HOME" instead of the value of the variable named
PYTHON_HOME. This commit fixes that as CMake expects
a path as the value of Python3_ROOT_DIR
Reviewers: #lldb, JDevlieghere, teemperor
Reviewed By: #lldb, JDevlieghere, teemperor
Subscribers: teemperor, JDevlieghere, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77842
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.
Richard Howell