This duplicates and renames the function `_add_swift_library_single`
into `_add_swift_host_library_single` and
`_add_swift_target_library_single`. This will allow for splitting up of
the two paths from the functions.
This is simply dropping the error that would be presented for any
existing usage. These have been rooted out for some time now. Remove
the obsoleted checks.
LLDB requires python3, however, gyb is a python2 tool. Use the fact
that we have a newer CMake at our disposal and use the `Python2` package
in CMake to locate a viable python interpreter. This allows us to have
references to both versions of python simultaneously.
* [build] use generator expression only on CMake > 3.15
In CMake < 3.16, Generator expressions seem not to allow the `LINKER:` prefix to be
expanded correctly when used in `target_link_options`.
To account for this, account for two code paths according to CMake version -- use the generator expression when detecting we are on 3.16 and resort to an if statement otherwise
Addresses rdar://problem/59117166
The `FILE_DEPENDS` option is used in exactly one location: swiftCore.
This prevention sets the groundwork for removing the option.
Dependencies should be tracked at the target level.
Hoist the responsibility for adding the linked libraries out of
`_add_swift_executable_single` to the invoker. This impacts only
`swift_add_target_executable`. This continues to bring the computation
of the properties nearer the site of definition.
Due to some unfortunate interplay between clang and libstdc++, clang was
not able to correctly identify to alignment of PoolRange and
SideTableRefCountBits, causing it to emit library calls instead of
inlining atomic operations. This was fixed by adding the appropriate
alignment to those types. In addition to that the march for the Linux
target was set to 'core2', which is the earliest architecture to support
cx16, which is necessary for the atomic operations on PoolRange.
Collate -F with the framework path to avoid unwanted deduplication of options by `target_compile_options` (which is the case after #29451) -- this way no undesired side effects are introduced should a new search path be added.
Addresses rdar://problem/58934566
Before the result of `_add_variant_c_compile_flags` was a string, so appending several "-isystem" was not a problem. With #29451 the rules have changed since the list is now handled by CMake, and it deduplicates the repeated members in the list. Thanks, CMake.
Should fix the Android CI builds that were failing since the merging of #29451.
This should repair the Windows build after #29451. The quoting
behaviour was incorrect and was constructing an invalid compiler
invocation. Solve the issue by using `target_include_directories`
instead. However, since this needs the target, hoist the flag
computation to the local sites. This replicates more logic because of
the custom build trying to replicate the CMake build logic in CMake.
This simplifies the ICU flags handling. This inlines the use into just
the library case, as the ICU usage is for the standard library targets
only. It uses CMake to properly add the include paths as a system
search path. This should fix the Linux builds as the include flags were
being de-duplicated as we are now using CMake more than we were
previously.
This was introduced in 2014. This should not be needed any longer,
especially with the use of the clang dependencies being satisfied by
export targets through `Clang_DIR`.
