todo: zap nix out of the build process #740
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/MSC
Matrix/Media
Meta
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: continuwuation/continuwuity#740
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Makes things simpler. Jade is apparently knowledgeable in a solution for this.
My current dockerfile, for reference:
Possibly could do with a couple enhancements, but is fully functional and running on matrix.ellis.link right now.
Statically linked binaries for standalone distribution require a bit more thought.
Packaging for RPMs & debs is also an option
Jade referenced this issue2025-04-14 20:59:05 +00:00
RPMs, debs, and standalone binaries are definitely something we'll need. Probably a PKGBUILD for arch, whatever it is nix uses this week, but RPMs/Debs/Standalone covers most of the prod server systems
Noting that it's been mentioned that nix is very helpful for static & cross-platform builds
At the moment we only support linux. We currently can't build for windows afaict, and don't support running on MacOS. We at least can do cross-architecture builds, though.
@Aranjedeath builds & runs on FreeBSD, and has mentioned that he can't use nix for that due to some of the native deps (it was either jemalloc or rocksdb)
I don't use and have never touched nix in my life; I solely use cargo build. If we put this into FreeBSD ports at some point, that is what it would use there.
I'll say, nix might be unwieldy, but it definitely helped with creating the static builds for the 0.5.0rc5 release, once I'd gotten over the bumps
Yeah, the Nix setup here includes a lot of automation for building binaries and installing relevant dependencies that would need to be replicated
Nix does not support *BSDs
We could have a separate CI flow for building BSD-specific binaries - I know the ones that we currently generate are also a bit of a pain on BSD sometimes
You will most definitely need to use emulation/virtualisation like
https://github.com/vmactions/freebsd-vm and it will be very slow. This
is what conduwuit planned to try using.
~ June 🏳️⚧️
Ideally, we wouldn't have to do that, but the issue is likely to be linked in system libraries. If we can get around that or bodge it somehow, we could get cross-compiles working. It's likely a similar story to what I did to get cross-arch Linux builds working in Docker, though.
That image is already using clang for building C deps, which supports cross-compilation to freebsd
x86_64-pc-freebsd<ver>
. It could be a matter of disabling some deps and vendoring in the rest.