If cmake is run on another machine, the default Xcode path and
more in the cmake cache and ninja files will be of that machine's
configuration, not the local machine's.
Test with:
./utils/build-script -r -- --distcc --verbose
The cmake lines should start with ``/usr/local/bin/cmake`` instead of with
``/opt/distcc/pump``.
rdar://problem/29942258
- <rdar://problem/27791475>
SwiftPM can now be built in release mode because all the outstanding
issues preventing that has been resolved. The major issues were:
* Building (and running) unit tests with @testable import in
* release. (swiftpm PR #758)
* Linker errors when building unit tests with wmo on linux. (SR-3034)
This was enabled in September (208e82f), and although it works most of the
time, we are running into some problems that depend on the specific version
of Clang. We should hold off using modules until they are more robust.
rdar://problem/29627138
This is a new version of my previous commit 411a05b7. I see now that
I had added the setting in code that is not used for Linux. This moves
it to a better place that should apply to all builds.
and its transitive closure of overlay dependencies.
[utils]:find-overlay-deps-closure.sh: Add a bash script to find the
closure of all other overlays required by a target overlay.
This reverts commit 411a05b753.
This did not work on Linux. Rather than fixing it in the build script,
I am changing the swift-llvm default for this setting to disable the checks.
The Swift runtime uses some header-only code from LLVM's ADT classes,
but we do not want to link libSupport into the runtime. These checks rely
on the presence of symbols in libSupport to identify how the code was
built and cause link failures for mismatches. Without linking that library,
we get link failures regardless, so instead, this just disables the checks.
- Add --libicu option to compile icu from source. This allows the
configuration to be controlled so that it is enabled for shared
and static building and the static files dont require the use of
the dynamic loader
- Add --install-libicu option to install the shared libraries into
$prefix/lib/swift and the static ones into $prefix/lib/swift_static.
This avoids interference with system installed versions
- Dont use find_package if building ICU from source
separate steps so that if the target does not exist the script will fail
instead of continuing. `set -e` is supposed to fix this, but since the
command is empty if the target doesn't exist, the subshell returns 0 and
the script continues.
Also, print out the cmake and ninja commands so that we don't hide so much
of the machinery.
Fixes rdar://problem/29003970
DaveA recently improved how we handle distcc with
880bd30286. Sadly this commit hit a landmine bug
created by a hack. Specifically there is some sort of code that is attempting to
sed ninja output (I don't completely understand what it is doing). My fix here
unblocks testing with distcc by just not using the hack when compiling with
distcc-pump.
I filed rdar://28874166 to investigate this issue.
* CMake deduces the path to some tools (ld, nm, objdump, ranlib, and
strip) from the path to the compiler. When the compiler is distcc, it
picks up the generic paths in /usr/bin instead of the one in the Xcode
being used, so set them explicitly in that case.
* Factor out the distcc command goop to be used for all cmake --build
invocations.
This reverts commit 0b1e8583a1.
No one remembers what problems this caused for the ASan bot when we
tried building the runtime with the just-built clang, so I'm reenabling
it now and we'll see what happens.
Clang-800 is crashing with C++ modules when building this version of LLVM.
Hopefully we can find a workaround. The crash is tracked
in rdar://problem/28739039
On Darwin, LLVM builds with -gmodules which causes debug info for the
types defined by the LLVM modules is stored alongside the modules in the
module cache. Deleting the module cache on every re-invocation of
build-script without re-building the LLVM and clang modules will erase
the debug info and thus render any LLVM types undebuggable.
rdar://problem/28655564
Turns out -DLLVM_ENABLE_ASSERTIONS does not actually enable assertions in LLVM!
What it actually does is rewrite the -DNDEBUG flag to be -UNDEBUG. This means
that we always want to pass in -DNDEBUG to swift. There are some complications
though. This means that we can not compile the C++ part of the runtime with a
different assertions setting than the swift compiler/llvm. This is a trade off
that for now we are ok with to get the no-asserts build working.
As part of a separate change, we are going to make -DLLVM_ENABLE_ASSERTIONS more
robust by doing what swift does now, putting -DNDEBUG or -UNDEBUG after CMake's
-DNDEBUG so we get the correct behavior of disabling or enabling assertions.
rdar://28485525
This patch resolves some post-commit feedback from @llvmbeanz. Specifically, the
only time that we need to hard code these flags are when compiling with
RelWithDebInfo since we need extra control in that case to ensure that CMake
does not sneak in a -g flag on the command line. This is important to ensure
that we are compiling with -gline-tables-only instead of -g.
Given that it is a performance fix specific to compiling with LTO with debug
info, we should no perform such a change when compiling with:
1. MINRELSIZE since we do not ever perform that build.
2. RELEASE since it does not have debug info.
3. DEBUG since why would one perform an LTO build in DEBUG mode.
In terms of 3, I can potentially imagine someone trying to compile Swift in
Debug with LTO to try to debug an LTO bug, but I imagine such a test case to be
such a rare need that there is no point in trying to make it faster.
