Now that `_add_swift_host_library_single` only deals with host
libraries, it is no longer mutating the name of the library target.
This `set_target_property` is no longer needed.
This reverts commit beb8ecd8cc. Add a
workaround for the dependency issue.
It is unclear why `sourcekitd` is getting added improperly as a
dependency on `lib/sourcekitd.framework/sourcekitd`. This workaround
adjusts the dependency such that we end up with a dependency on
`lib/sourcekitd.framework/Versions/A/sourcekitd` as an order-only
dependency. This should fix the compile issue. I am unable to
reproduce this issue with the `add_library` usage for adding a Swift
library. This allows us to cleave the host and target libraries, and so
the workaround is sufficient to make progress and the problem will be
resolved with the migration towards CMake for handling the dependencies.
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.
* [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
