Closed mneumann closed 1 year ago
I have no problem merging this (so I'm marking it as approved).
However, if we want to officially support DragonFly we'll need a way to run CI builds for it. So for now this will be an "unofficial/best-effort support" level.
It'd be good to have official support for DragonFly or just CI. Same for OpenBSD / NetBSD. It should be easy to add support for these. Concerning CI - you could not run the spec
on DragonFly, and this is the part that most likely exhibits errors. So it would be only a continuous build. There is not much that could fail here.
Maybe it's possible to use a FreeBSD runner on CirrusCI but use some particular
clang
magic to "cross-compile" to DragonFly?
That would probably work. IIRC, I once did that for Rust where I just used the DragonFly live ISO image that contains all sources and libraries. Another option is to run a virtualized DragonFly from Cirrus via qemu (not sure if this would work).
For now I concentrate on a DragonFly ports
definition.
Closing in favor of #381
There are still problems when linking the final
savi
binary, but that seems to be related to not having the static LLVM binaries available on DragonFly (yet).There are two open tasks for getting Savi on DragonFly:
libsavi_runtime
Both are more difficult to build via github actions or cirrus CI, as they don't have DragonFly runners.
Once I get things working, I can provide a
savi
port for DragonFly that can be installed aspkg ins savi
. Though, I am a bit concerned about the LLVM dependency... building non-standard LLVM as a dependency of asavi
port take too much CPU. Hoping that they change the default of shipping with the static libs in the next version (of the DragonFly / FreeBSD port).