Create a helper function to determine if we are targeting a Darwin SDK or not.
The repetition is error-prone and verbose. Simplify by adding a checking
function. NFC.
Use the SWIFTLIB_SINGLE_SDK variable rather than the CMAKE_BUILD_SYSTEM variable
to determine the target type. This allows us to use the logic for adding
libraries for foreign OSes on a build host. This is needed to pave the road to
cross-crompiling the standard library for different targets.
The use of `-isysroot` is a Darwin specific behaviour. It is used to switch to
a platform SDK, however, other targets use the `--sysroot` flag. Windows uses a
custom mechanism which is a set of system header paths.
llvm/Support/Compiler.h recently grew a dependency on llvm-config.h. This
pointed out that we were not including the path to the generated header
directory in the build output. Ensure that we have the corresponding -I.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
HOST_LIBRARY is supposed to mean "no matter what the defaults say, also build
this library for the host". FORCE_BUILD_FOR_HOST_SDK is a less confusing name.
At some point in the future, we may consider using LTO on the runtime/standard
library, but right now is not that time. We are just trying to use LTO to
improve the compile time performance of the compiler itself.
rdar://24717107
This will allow control on the outside of these calls on whether or not LTO is
enabled. This is necessary for turning off LTO on target libraries.
rdar://24717107
*NOTE* We are still passing this variable into LLVM. Just not into Swift anymore.
I originally passed in the variable -DLLVM_ENABLE_LTO=YES to Swift's cmake to
ensure that the Swift unittests were compiled with lto. That was the wrong
fix.
The reason why is that if -DLLVM_ENABLE_LTO is set to YES then HandleLLVMOptions
in llvm will append -flto to both CMAKE_C_FLAGS and CMAKE_CXX_FLAGS implying
that -flto can not be disabled selectively. This ability to disable flto
selectively is something that we need in order to lto host libraries, but not
lto target libraries.
Thus in this commit, we no longer pass in -DLLVM_ENABLE_LTO=YES to swift's cmake
invocation. Instead we apply the lto flag to the unittest target ourselves in
add_swift_unittest.
rdar://24717107
The Swift driver does not update the mtime of the output files if the
existing output files on disk are identical to the ones that are about
to be written. This behavior confuses the makefiles used in CMake Xcode
projects: the makefiles will not consider everything up to date after
invoking the compiler. As a result, the standard library gets rebuilt
multiple times during a single build.
To work around this issue we touch the output files so that their mtime
always gets updated.
not IS_STDLIB. There are other non-stdlib libraries that can go
into the platform resource directory, such as libswiftRemoteMirror.dylib.
rdar://problem/26435454
Although this is a target library, it does not need to link against
the standard library, because it doesn't have any Swift content in
it. We need to add a separate build flag for having CMake content
because saying a library "IS_STDLIB" isn't correct for this case.
rdar://problem/26399625
GNU ld seems to have problems with PC-relative references to
protected functions that aren't calls. We'll generate that
pattern in Swift code in release builds because of function
merging. The workaround is to just not tell the compiler
that these symbols can be addressed PC-relative when we might
be using GNU ld, which I've conservatively approximated as
"not Darwin" while I try to figure out what changed to cause this.
Declarations with protected visibility are assumed to be defined
within the current linkage unit, so we have to use default visibility
if we don't know that we're building that. Teach the shim
visibility header to only use protected visibility when the
__SWIFT_CURRENT_DYLIB macro is defined, and define it when building
the standard library. Eventually we should change
SWIFT_RUNTIME_STDLIB_INTERFACE and SWIFT_RUNTIME_EXPORT to be
parameterized by the defining dylib so that this works for all the
overlay stubs, too; for now, special-casing swiftCore is necessary
to fix the LInux build.
A script checks if the output object file is written only once even if the compiler is invoked multiple times.
The main purpose of this check is to ensure that the compiler is deterministic (until IRGen).
Create a new CMake file responsible for functions that handle Swift
source files, such as `handle_swift_sources`. Also, add a new function,
`add_swift_source_group`, to this file. This function reduces some
duplication in `AddSwift.cmake`.
Otherwise, we may get lipo from the wrong toolchain and it may not be
able to understand all of the architectures/bit code we are lipoing
together yielding an unknown architecture error.
rdar://24717107
These types are not directly referenced as fields of aggregate types,
but are needed for reflection type lowering.
Also, use a SetVector to collect referenced builtin types, instead of
a SmallPtrSet, to ensure compiler output is deterministic.
