Fix building and testing on FreeBSD; Add FreeBSD platform support #8193
Conversation
michael-yuji
requested review from
bnbarham,
MaxDesiatov,
jakepetroules,
francescomikulis,
xedin,
dschaefer2,
shawnhyam,
bripeticca,
plemarquand,
owenv and
bkhouri
as code owners
|
@swift-ci test |
| @@ -16,11 +16,12 @@ public enum SystemPackageProviderDescription: Hashable, Codable, Sendable { | |||
| 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
| @@ -201,7 +201,7 @@ let package = Package( | |||
| name: "Basics", | |||
| dependencies: [ | |||
| "_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.
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