JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 10:15:20 +01:00

[GH-ISSUE #490] Provide binaries for every release in Github releases #161

New issue

Closed

opened 2026-05-22 21:51:31 +01:00 by JakeStanger · 8 comments

JakeStanger commented

2026-05-22 21:51:31 +01:00

Owner

Originally created by @VarLad on GitHub (Mar 11, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/490

Providing statically compiled binaries would make it much easier for users to simply try the software in the first place.
Since it has a lot of dependencies, compiling it from scratch is a pain on older systems.
You might point towards distro packaging but having binaries helps with some immutable distros where packages are not feasible.

Originally created by @VarLad on GitHub (Mar 11, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/490 Providing statically compiled binaries would make it much easier for users to simply try the software in the first place. Since it has a lot of dependencies, compiling it from scratch is a pain on older systems. You might point towards distro packaging but having binaries helps with some immutable distros where packages are not feasible.

JakeStanger closed this issue

2026-05-22 21:51:31 +01:00

JakeStanger commented

2026-05-22 21:51:31 +01:00

Author

Owner

@yavko commented on GitHub (Mar 11, 2024):

This shouldn't be too hard since ironbar is built on every commit, the only difference would be setting a build artifact so you could download from every GH action, and maybe also an action that builds in release on a new tag

@yavko commented on GitHub (Mar 11, 2024): This shouldn't be too hard since ironbar is built on every commit, the only difference would be setting a build artifact so you could download from every GH action, and maybe also an action that builds in release on a new tag

JakeStanger commented

2026-05-22 21:51:31 +01:00

Author

Owner

@slowsage commented on GitHub (Mar 15, 2024):

This may help (was rejected since I did not think through targets/environments etc.): #227

@slowsage commented on GitHub (Mar 15, 2024): This may help (was rejected since I did not think through targets/environments etc.): #227

JakeStanger commented

2026-05-22 21:51:31 +01:00

Author

Owner

@JakeStanger commented on GitHub (Mar 16, 2024):

I think providing binaries for each tagged release is sensible. I won't add them to the CI build on every push because that will generate a lot of noise (plus if you're following Git you're surely happy to build from source, right? :p)

The main questions I guess is how and in what format(s). Supporting x86_64 and (possibly) ARM64 sounds like a good idea to me.

What considerations are there around different C stdlibs (GNU, Musl) or anything like that? I'm not too clued up there and see there was some reference to those in the above PR.

@JakeStanger commented on GitHub (Mar 16, 2024): I think providing binaries for each tagged release is sensible. I won't add them to the CI build on every push because that will generate a lot of noise (plus if you're following Git you're surely happy to build from source, right? :p) The main questions I guess is how and in what format(s). Supporting x86_64 and (possibly) ARM64 sounds like a good idea to me. What considerations are there around different C stdlibs (GNU, Musl) or anything like that? I'm not too clued up there and see there was some reference to those in the above PR.

JakeStanger commented

2026-05-22 21:51:31 +01:00

Author

Owner

@slowsage commented on GitHub (Mar 20, 2024):

I suggest we avoid musl and stick to gnu based on ironbar's multi-threading and musl's memory allocator having perf issues: https://github.com/nextstrain/nextclade/issues/1338.

I can try https://github.com/marketplace/actions/build-rust-projects-with-cross and get back if this makes sense for aarch64-unknown-linux-gnu and x86_64-unknown-linux-gnu.

@slowsage commented on GitHub (Mar 20, 2024): I suggest we avoid musl and stick to gnu based on ironbar's multi-threading and musl's memory allocator having perf issues: https://github.com/nextstrain/nextclade/issues/1338. I can try https://github.com/marketplace/actions/build-rust-projects-with-cross and get back if this makes sense for `aarch64-unknown-linux-gnu` and `x86_64-unknown-linux-gnu`.

JakeStanger commented

2026-05-22 21:51:31 +01:00

Author

Owner

@yavko commented on GitHub (Mar 20, 2024):

I suggest we avoid musl and stick to gnu based on ironbar's multi-threading and musl's memory allocator having perf issues: nextstrain/nextclade#1338.

I can try github.com/marketplace/actions/build-rust-projects-with-cross and get back if this makes sense for aarch64-unknown-linux-gnu and x86_64-unknown-linux-gnu.

Just cuz its slower, shouldn't be a reason to prevent users from using it, tho. Also, as the issue mentioned, it could be made better with the use of a different allocator like jemalloc, which is pretty easy with rust.

@yavko commented on GitHub (Mar 20, 2024): > I suggest we avoid musl and stick to gnu based on ironbar's multi-threading and musl's memory allocator having perf issues: [nextstrain/nextclade#1338](https://github.com/nextstrain/nextclade/issues/1338). > > I can try [github.com/marketplace/actions/build-rust-projects-with-cross](https://github.com/marketplace/actions/build-rust-projects-with-cross) and get back if this makes sense for `aarch64-unknown-linux-gnu` and `x86_64-unknown-linux-gnu`. Just cuz its slower, shouldn't be a reason to prevent users from using it, tho. Also, as the issue mentioned, it could be made better with the use of a different allocator like jemalloc, which is pretty easy with rust.

JakeStanger commented

2026-05-22 21:51:31 +01:00

Author

Owner

@JakeStanger commented on GitHub (Mar 20, 2024):

Let's stick to GNU for now in that case. We can revisit musl separately if there's demand for it, and handle the perf/allocator issue then.

Feel free to try any actions or work flow changes out and see how it goes.

@JakeStanger commented on GitHub (Mar 20, 2024): Let's stick to GNU for now in that case. We can revisit musl separately if there's demand for it, and handle the perf/allocator issue then. Feel free to try any actions or work flow changes out and see how it goes.

JakeStanger commented

2026-05-22 21:51:31 +01:00

Author

Owner

@slowsage commented on GitHub (Mar 20, 2024):

Tested #504 on my repo. (Re-forked later to clean up tags).
Decided not to change the existing yml files to keep this separate and avoid dependencies. The setup is pretty quick till cross gets the docker images anyway.
Update: Typed too soon. The issue is:

Without a vendored openssl, the binary gets built against openssl 1.1 since cross is stuck with ubuntu focal. The binary runs fine with openssl1.1.

Making it vendored breaks the garnix ci check which I'm not sure how to fix [I'm not on nix].

Any help/thoughts appreciated.

@slowsage commented on GitHub (Mar 20, 2024): Tested #504 on my repo. (Re-forked later to clean up tags). Decided not to change the existing yml files to keep this separate and avoid dependencies. The setup is pretty quick till cross gets the docker images anyway. Update: Typed too soon. The issue is: Without a vendored openssl, the binary gets built against openssl 1.1 since cross is stuck with ubuntu [focal](https://github.com/cross-rs/cross/issues/1276). The binary runs fine with openssl1.1. Making it vendored breaks the garnix ci check which I'm not sure how to fix [I'm not on nix]. Any help/thoughts appreciated.

JakeStanger commented

2026-05-22 21:51:32 +01:00

Author

Owner

@slowsage commented on GitHub (Mar 21, 2024):

Found a workaround - will add openssl vendored just for the binary.yml till the cross-rs image gets updated. This leaves Cargo.toml as is and passes garnix ci build checks.

@slowsage commented on GitHub (Mar 21, 2024): Found a workaround - will add openssl vendored just for the binary.yml till the cross-rs image gets updated. This leaves Cargo.toml as is and passes garnix ci build checks.

JakeStanger referenced this issue

2026-05-22 21:53:46 +01:00

[PR #161] [MERGED] build(deps): bump serde from 1.0.160 to 1.0.163 #519

JakeStanger referenced this issue

2026-05-22 22:55:20 +01:00

[PR #161] [MERGED] build(deps): bump serde from 1.0.160 to 1.0.163 #1927

JakeStanger referenced this issue

2026-05-22 23:55:30 +01:00

[PR #161] [MERGED] build(deps): bump serde from 1.0.160 to 1.0.163 #3333

JakeStanger referenced this issue

2026-05-23 00:55:17 +01:00

[PR #161] [MERGED] build(deps): bump serde from 1.0.160 to 1.0.163 #4738