-
Notifications
You must be signed in to change notification settings - Fork 10.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partial FreeBSD Support #203
Partial FreeBSD Support #203
Conversation
The alternative to _WITH_GETLINE would be to define _POSIX_C_SOURCE >= 200809.
Nice! @gribozavr is probably the best person to review the build system changes. |
@landonf Great work! Please update the pull request per comments above. Which systems have you tested this branch on? |
When these diverge, we can use the Unix toolchain as a common baseclass for both.
Thanks for the feedback; I believe I've integrated all the requested changes. I also moved ahead with a common Unix toolchain class pending additional comments on a preferred alternative. I've only tested locally against x86-64-freebsd10.2 (-STABLE) |
I'll run the tests on OS X and Linux, while waiting for feedback from @jrose-apple . |
@landonf The OS X build passed all tests. The new test fails on Linux.
I think this is because the FreeBSD toolchain is being disabled on Linux with a |
@gribozavr My fault for dropping SWIFT_ENABLE_TARGET_FREEBSD without verifying that it didn't break lib/Driver/CMakeLists.txt target define handling. How did you want to handle this for Linux? Should we just enable both targets by default? Or should I bring back SWIFT_ENABLE_TARGET_FREEBSD and make the tests conditional on the targets being enabled? |
@landonf I'd prefer that we drop the Linux option, too. |
@landonf In fact, I'll do it now, give me an hour. |
In the spirit of incremental development, can we do these as separate pull requests? Drop SWIFT_ENABLE_TARGET_LINUX, rename toolchain and fix-up the Driver library in preparation for the main change, then actually add the support. Or whatever units make sense to you. (Feel free to rewrite history ahead of the merges.) Aside: Sorry for the trouble, Landon. I'm/We're very happy to have you working on this even as I'm pushing for this extra process. Having small, logically distinct commits is especially important if we ever need to bisect a failure—it's better to be able to isolate a specific change rather than potentially having to revert the whole merge commit. Also, once a change is in master, others are held accountable for not breaking it. :-) |
I'm dropping SWIFT_ENABLE_TARGET_LINUX in a separate change. |
@gribozavr Thanks! No problem; I've merged in the changes (and adopted @jrose-apple's suggested "GenericUnix"). |
Running tests again. |
@landonf The diff --git a/test/BuildConfigurations/x64FreeBSDTarget.swift b/test/BuildConfigurations/x64FreeBSDTarget.swift
index 619d4f5..284060f 100644
--- a/test/BuildConfigurations/x64FreeBSDTarget.swift
+++ b/test/BuildConfigurations/x64FreeBSDTarget.swift
@@ -1,5 +1,5 @@
-// RUN: %swift -parse %s -verify -D FOO -D BAR -target x86_64-freebsd10 -disable-objc-interop -D FOO -parse-stdlib
-// RUN: %swift-ide-test -test-input-complete -source-filename=%s -target x86_64-freebsd10
+// RUN: %swift -parse %s -verify -D FOO -D BAR -target x86_64-unknown-freebsd10 -disable-objc-interop -D FOO -parse-stdlib
+// RUN: %swift-ide-test -test-input-complete -source-filename=%s -target x86_64-unknown-freebsd10
#if arch(x86_64) && os(FreeBSD) && _runtime(_Native)
class C {} With this patch, tests pass on Linux and OS X. |
Thanks, will do; I'm going to bring up a Linux machine so I can properly test locally. |
This reverts: - Adopt proper freebsd triple as required by Swift's build system. - Revert "Add FreeBSD target_* support. These will be re-introduced in a later patch that brings up the FreeBSD test suite.
@gribozavr Great; patchset now matches your change. |
TC = new toolchains::Linux(*this, Target); | ||
TC = new toolchains::GenericUnix(*this, Target); | ||
break; | ||
case llvm::Triple::FreeBSD: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just let this fall through instead of duplicating code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed via 109d8e6, thanks!
Does this change means that most
|
Yes, all these places need to be audited (we tried to write them in such a way that a new platform would cause build breakage rather than silently choosing some behavior), but not all of them would become |
Many of the conflicts stemmed from FreeBSD support, added in swiftlang#203. Conflicts: - CMakeLists.txt - cmake/modules/AddSwift.cmake - lib/Basic/LangOptions.cpp - lib/Driver/ToolChains.cpp - stdlib/public/Glibc/CMakeLists.txt - stdlib/public/core/CMakeLists.txt - stdlib/public/runtime/CMakeLists.txt - stdlib/public/runtime/Casting.cpp - stdlib/public/stubs/CMakeLists.txt - stdlib/public/stubs/LibcShims.cpp - stdlib/public/stubs/Stubs.cpp - test/CMakeLists.txt - utils/build-script-impl
update libpwq and libkqueue submodule versions
update libpwq and libkqueue submodule versions Signed-off-by: Daniel A. Steffen <[email protected]>
Delete the OpenBraceWhitespace rule.
Update hash for IBAnimatableApp to build with Swift 4
- Use durable GUID generation for auto-generation of the GUID. - Combine the platform definitions into a singular source to avoid drift. This avoids having to keep the variants in sync and provides an easier upgrade path. This is the first step towards enabling a non-admin experience for users.
This provides a non-controversial baseline for FreeBSD support.
Additional work will be required for the full port, but with this initial work -- plus local work-arounds for linker script behavior and use of pkg-installed libc++ -- I'm able to successfully compete a full Swift build on FreeBSD 10.x.