These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
- CYGWIN symbol is used to distinguish Cygwin environment from other OS
and other environment in Windows.
- Added windows and windowsCygnus to OSVersion in StdlibUnittest
pthreads is not available on non-POSIX platforms (i.e. Windows). Restrict the
target platforms that we build SwiftPrivatePthreadExtras and things which depend
on it.
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.
Update tests to match, and rewrite SwiftPrivatePthreadExtras to take advantage of native C function pointer support instead of hacking it up through a stub C++ library.
Swift SVN r27604
Update tests to match, and rewrite SwiftPrivatePthreadExtras to take advantage of native C function pointer support instead of hacking it up through a stub C++ library.
Swift SVN r27598
These should all apply to any Darwin platform, and the current behaviour
was breaking cross-compilation.
Introduces a SWIFT_DARWIN_VARIANTS pattern, to be used as follows:
if(SWIFT_HOST_VARIANT MATCHES "${SWIFT_DARWIN_VARIANTS}")
Also fix one place where I checked the CMAKE_SYSTEM_NAME instead of the
host variant that I recently introduced. I haven't attempted to find
the rest of the places we're doing this though.
Swift SVN r26554
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
