This reverts commit 9e628b0f2d.
If LLVM was built with --disable-dylib, then the individual
LLVM libraries may expose a dependency on zlib. By restricting
the lldb-mi build to detect dependencies outside of $LLVM_DIR,
the build of lldb-mi fails to find zlib, making it impossible to
find all the necessary dependencies, ending up with errors like this:
CMake Error at llvm-mingw/llvm-project/llvm/build-asserts/lib/cmake/llvm/LLVMExports.cmake:55 (set_target_properties):
The link interface of target "LLVMSupport" contains:
ZLIB::ZLIB
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Revert this change for now, to allow building lldb-mi against
a non-dylib build of LLVM.
Do the same as when cross compiling; disallow detecting dependencies
outside of the given CMAKE_FIND_ROOT_PATH. Don't export LLVM_DIR
as we no longer need to pass it implicitly that way.
This makes the errors clearer, if LLVM isn't found where expected,
instead of misdetecting it from a different installation of LLVM
in the system.
If lldb-mi would try to find other optional dependencies, they would
no longer be found; this was already the case when cross compiling
though.
As build-llvm now can create a larger variety of build dir names,
enumerating all possible suffixes becomes problematic (especially
as they don't necessarily appear in one canonical order).
Instead, iterate over potential matches. If cross compiling, it
is easy as we can require the directory to contain the expected
suffix. If not cross compiling, we have no explicit suffix to look
for, but we can check that the directory doesn't match common
cross compilation triples.
CMake 4.0 removed compatibility with CMake versions below 3.5.
Therefore, it errors out on projects with a
cmake_minimum_required() less than 3.5.
(Since CMake 3.31, it already warns that compatibility with versions
below 3.10 is deprecated.)
By passing CMAKE_POLICY_VERSION_MINIMUM=3.5, we indicate that
we are ok with configuring this project with the policies of
CMake 3.5, even if the project files themselves don't state it.
This flag is only recognized by CMake 4.0; older versions will
only warn that the manually specified variable is unused.
This allows simplification, this functionality was added long
ago to CMake.
Further motivation is to be able to re-direct the installation,
make/ninja install allow this by setting DESTDIR but this
generally doesnt work well with window paths (see [1]).
[1] - https://cmake.org/cmake/help/latest/envvar/DESTDIR.html#envvar:DESTDIR
Since the switch to building in C++17 mode in llvm 16, lldb-mi is
incompatible, until lldb-mi itself switches to building with C++17 too.
A fix has been suggested upstream in
https://github.com/lldb-tools/lldb-mi/pull/102, but there hasn't
been any action on it so far.
When rebuilding in an already built directory, cmake does use
the cache file, containing what variables were set to previously.
When changing build configuration (building with a different prefix,
or changing build configurations) this can often result in failed
cmake runs.
Wipe the cache (and the rest of the cmake temp files) by default.
This makes sure that the full cmake configuration is run each time
when running the build scripts, just like it does the first time.
(This doesn't remove the build artifacts; if nothing of significance
has changed, ninja would still reuse old built files.)
By setting the env variable NO_RECONF, this behaviour can be skipped,
rerunning cmake without wiping the cache inbetween. (For cases where
the user knows that the configuration hasn't changed since the last
build, this can speed up the cmake execution time a bit.)
This command isn't a standard tool; different distributions have
different implementations, and e.g. Fedora doesn't ship it by
default.
Settle on using "command -v $tool >/dev/null" for tests about whether
a tool is available. (We could also use "hash $tool 2>/dev/null" as we
already had in build-all.sh, but settling on using "command -v"
everywhere, for consistency and simplicity.)
This includes building universal binaries (for arm64 and x86_64)
and targeting an older minimum deployment target.
(Before 1919720fdd348ca568b235bf3f1357c198eccd15 in llvm-project,
Jan 2022, building lldb's debugserver failed, if building for macOS
for multiple architectures, or for an architecture other than the
current host.)
Building this tool requires having a full LLVM build available;
either by installing without LLVM_INSTALL_TOOLCHAIN_ONLY (and not
stripping the llvm installation yet) or by pointing it at the
LLVM build directory instead. The latter works better for our
normal build flows.
Martin Storsjö