Fix building and testing on FreeBSD; Add FreeBSD platform support #8193
Conversation
michael-yuji
requested review from
MaxDesiatov,
bkhouri,
bnbarham,
bripeticca,
dschaefer2,
francescomikulis,
jakepetroules,
owenv,
plemarquand,
shawnhyam and
xedin
as code owners
|
@swift-ci test |
| case apt([String]) | ||
| case yum([String]) | ||
| case nuget([String]) | ||
| case pkg([String]) |
There was a problem hiding this comment.
Is FreeBSD's pkg sufficiently "branded" to call it this? OpenBSD's package manager is named quite similarly, and while it doesn't seem to have a formal name, all of its commands begin with pkg_. pkg also isn't a particularly searchable term.
pkg might still be the right choice, but I just want to make sure we're doing the thought exercise of considering the best name in the context of all the largest 4 BSDs (FreeBSD, OpenBSD, NetBSD, and DragonflyBSD) and what would be least confusing, even if we're not adding those others right now.
Here's some of my thoughts:
- NetBSD's
pkgsrcis not exclusive to NetBSD, and has its own website / identity / branding. So I think an enum namedpkgsrcwould make sense there. - OpenBSD's package system doesn't have a name. Call the enum
openbsd_pkg? - FreeBSD's package system doesn't have a name, and DragonflyBSD's package management software (as far as I can tell) is a fork of FreeBSD's (as is the OS generally). Two enums
freebsd_pkganddragonflybsd_pkg? Or a single enumpkgthat applies to both FreeBSD and DragonflyBSD? That might be a bad idea though, as they are different OSes which may have diverged.
There was a problem hiding this comment.
This is also in my mind, originally I name this pkgng, but pkgng renamed to pkg quite a while ago. https://wiki.freebsd.org/pkg. DragonflyBSD is using the same pkg from FreeBSD https://github.com/DragonFlyBSD/DPorts/blob/master/ports-mgmt/pkg/Makefile.
I'm not sure about OpenBSD tho, and currently the SystemPackageProviderDescription enum does not include one for it.
There was a problem hiding this comment.
OK, might be worth starting a Swift evolution thread on the naming. In the meantime you could land this behind an API availability of 999.0
| "_AsyncFileSystem", | ||
| .target(name: "SPMSQLite3", condition: .when(platforms: [.macOS, .iOS, .tvOS, .watchOS, .visionOS, .macCatalyst, .linux])), | ||
| .target(name: "SPMSQLite3", condition: .when(platforms: [.macOS, .iOS, .tvOS, .watchOS, .visionOS, .macCatalyst, .linux, .custom("freebsd")])), | ||
| .product(name: "SwiftToolchainCSQLite", package: "swift-toolchain-sqlite", condition: .when(platforms: [.windows, .android])), |
There was a problem hiding this comment.
Great to see this port moving forward. 🥲
Have you tried using this SQLite package instead? The only reason most OSs above don't is that this is new: I switched my upcoming native 6.1 toolchain for Android over to using it and was able to remove the external libsqlite package dependency of this Swift toolchain as a result. I suggest you try the same, will require patching llbuild also.
There was a problem hiding this comment.
Ah, I just saw your comment. This sounds like a good idea! Thanks!
michael-yuji
force-pushed
the
freebsd-wip
branch
from
d926944 to
c425839
Compare
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test Windows |
|
@swift-ci please test |
| # Enable `package` modifier for the whole package. | ||
| add_compile_options("$<$<COMPILE_LANGUAGE:Swift>:-package-name;SwiftPM>") | ||
| if(CMAKE_SYSTEM_NAME STREQUAL FreeBSD) | ||
| add_compile_options("$<$<COMPILE_LANGUAGE:Swift>:-package-name;SwiftPM>" -L/usr/local/lib) |
There was a problem hiding this comment.
nit: may be worth a comment that the /usr vs /usr/local separation is a formal FreeBSD policy for all ports not part of the base system, otherwise this difference may look suspicious to future readers (it was to me, as I mentioned to you elsewhere)
|
@swift-ci test linux |
|
@swift-ci test windows |
4 participants
Fix building and testing on FreeBSD and add support for "FreeBSD" platform
Motivation:
Adding support for "FreeBSD" is swiftpm is necessary to get a usable toolchain building on FreeBSD.
Modifications:
Archiver
On FreeBSD, the
unzipcommand is available in base but not thezipcommand. Therefore; we use libarchive (viabsdtar) to produce ZIP archive instead.The implementation is also based on
libarchivewhich produces different error messages; Tests are updated accordinglycompile / link arguments
FreeBSD ships with libc++ by default hence should use
-lc++. Like Linux,defsymis also required to link targets with_mainsymbol.FreeBSD native package manager (
pkgng) support:FreeBSD uses
pkgngas its package manager,Result:
Should be able to build swiftpm on FreeBSD. Testing on
x86_64 FreeBSD 14.2 RELEASE