Ensure that we build all the target libraries with the correct build
configuration. This is needed on Windows where the different MSVC
runtime libraries are ABI incompatible.
These properties are extraneous. They are never queried, and the
`set(...CACHE)` which precedes them will ensure that the value is
cached. This should be functionally equivalent.
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
Preconditions have been moved to the top of the file. All the variables set have been grouped by kind and a few converted to cache variables for better control when building. This should cut down on merge-conflicts as well."
clang/cmark are only needed for the tools, not for the runtime/SDK
overlay. Do not attempt to configure clang and CMark in the case we do
not build the tools. This is needed to enable the standalone standard
library only builds.
Now that that's stabilized, we don't have to keep them in Swift 4 mode
any longer. (Arguably we don't need the CMake variable at all, but it
may be useful again in the future.)
rdar://problem/49040980
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
The standard library does not depend on the LLVM libraries at runtime. Do not
perform the search for the LLVM configuration when the tools are not being
built. This is needed to permit cross-compiling the standard library standalone
for android on a Linux host without building LLVM and Clang for android.
This adjusts the windows build for cross-compiling to use the correct
variable. Import libraries will be generated and tracked properly if
the CMAKE_SYSTEM_NAME is set to Windows. It does not matter what the
build system is.
Copy the runtime component into the swift runtime directory. Normally
the runtime directory is not the same as the library directory on
Windows. This copies the runtime component into the build tree into the
runtime directory to permit the tests to find the standard library.
Rather than have the ICU handling be pushed down into the library handling, this
will move it into the CFLAGS calulation which was being augmented previously.
It is a cleanup that makes it easier to reason about the flags handling.
Adjust the `c_compile_flags` variable to ensure that the flags are ordered
correctly. This is of import for the android build which may end up using
invalid header search path ordering otherwise. This ensures that the path
for the ICU includes comes after the C++ headers which is necessary in new
C++ releases which shadow math.h
Move the ICU flag handling to the same area as `_c_compile_variant_flags` which
computes the C compile flags. This allows us to ensure that we order the flags
correctly when they are merged into the `c_compile_flags`.
The CMake variables ${sdk} and ${arch} are only set if
_add_variant_link_flags is invoked from add_swift_target_library calling
_add_swift_library_single. If you get to _add_swift_library_single from
add_swift_host_library, those variables will not be set and subsequent
linking will not find ICU libraries. This was an issue when building
swift host libraries on Android.
This is needed as SwiftSyntaxParser also needs to be built with clang as
it uses blocks unconditionally. However, building with cl provides much
better diagnostics and debugging as well as a significantly faster
build (~15-20% faster) as well as a faster compiler.
I also removed the -verify-sil-ownership flag in favor of a disable flag
-disable-sil-ownership-verifier. I used this on only two tests that still need
work to get them to pass with ownership, but whose problems are well understood,
small corner cases. I am going to fix them in follow on commits. I detail them
below:
1. SILOptimizer/definite_init_inout_super_init.swift. This is a test case where
DI is supposed to error. The only problem is that we crash before we error since
the code emitting by SILGen to trigger this error does not pass ownership
invariants. I have spoken with JoeG about this and he suggested that I fix this
earlier in the compiler. Since we do not run the ownership verifier without
asserts enabled, this should not affect compiler users. Given that it has
triggered DI errors previously I think it is safe to disable ownership here.
2. PrintAsObjC/extensions.swift. In this case, the signature generated by type
lowering for one of the thunks here uses an unsafe +0 return value instead of
doing an autorelease return. The ownership checker rightly flags this leak. This
is going to require either an AST level change or a change to TypeLowering. I
think it is safe to turn this off since it is such a corner case that it was
found by a test that has nothing to do with it.
rdar://43398898
A typo snuck into the cross-compiling path and due to the machine that it was
tested on hvaing `/bin/llvm-tblgen`, the build succeeded. Correct the typo to
ensure that we use the correct tblgen.
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
This was used for the swift-reflection-test tool. Instead of using fat
binaries, use the target binary itself. This simplifies the build logic
as well as paves the road to sub-builds for each target rather than a
monolithic build as we have today.
Originally, the swift-reflection-test was a host tool that linked
against the target libraries since it was testing the target layout.
Now that the tool has been split into a host and target component
(5ea5bb06a3) and we have target and host
libraries that we can link against appropriately, we do not need to link
against the FAT binary. Since there was exactly one use of this
functionality, switching that from fat linking to regular linking allows
us to remove this functionality entirely. Switch to regular linking and
remove the option.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
This is not currently being used. Unfortunately, setting linker options
is difficult until CMake 3.13 which introduced target_link_options.
Prior to that, you needed to do:
set_property(TARGET <TARGET> APPEND_STRING LINK_FLAGS <NEW FLAGS>)
If needed, we could write a helper to provide the target_link_options
interface on earlier CMake versions.
