search

gridcoin-community / Gridcoin-Research

Gridcoin-Research
MIT License
585 stars 173 forks source link

Add Static Linux Builds to CD #2456

Open RoboticMind opened 2 years ago

RoboticMind commented 2 years ago

Feature Request

Describe the Feature Request The current CD deployment only covers Windows and MacOS builds. Adding a static Linux build would help make sure everyone has a build ready even if each distribution's build isn't ready yet. This may be especially important if a new release needs to be made for security reasons in the future. Github Action's cache system could be used to cache the depends builds and avoid making the builds take a long time.

Describe Alternatives If Flatpack or any other more universal Linux packaging system is used, that would give the same benefit. It might just take more work to make that happen.

There also could be a build for each distribution, but this seems like it would be more work to maintain automated scripts for.

caraka commented 2 years ago

I built a gridcoin snap for over 6 months and couldn't find anyone to even test it on testnet. This was a while ago, and familiarity with snaps was much lower. I'm happy to revive the effort if people think it would get used. I always thought of it as a way to support less common distros. I was building 4.0.0 + for testnet. Guess that was a while ago!

jamescowens commented 2 years ago

I would rather do depends style static builds than snap builds.

jamescowens commented 2 years ago

Until we get this automated, I am adding static Linux x86_64 builds to the release assets. I am providing both bdb48 and bdb53 versions.

hunleyd commented 2 years ago

Until we get this automated, I am adding static Linux x86_64 builds to the release assets. I am providing both bdb48 and bdb53 versions.

did these make it into the 5.4.0.0 release @jamescowens ?

jamescowens commented 2 years ago

I haven't built them yet for the release.

APCBoston commented 6 months ago

@caraka @div72 I'm interested in taking this one on. Jim mentioned in the discord that I should check in with the two of you.

div72 commented 6 months ago

@APCBoston @jamescowens Copying the job with depends should be enough in this case, but we do get this for free with #2689.

APCBoston commented 6 months ago

I was thinking of not just caching the build but automating the creation of .deb and .rpm packages including for ARM; my understanding is that all of that is currently done manually with each release. I don't expect it to be a huge lift and that plus something "universal" like a flatpak, appimage, or heaven forbid, a snap, would increase accessibility particularly for less-technical Linux users (yes they exist), decrease the delay from the tagging of a new release to the availability of packages for that release, and take the load off the individuals who are currently doing that packaging manually.

As far as comparing this work to #2689 , copying Jim's comment from the Discord:

I like the idea [of automating deb and rpm builds]. It probably means I will NOT adopt https://github.com/gridcoin-community/Gridcoin-Research/pull/2689, because I don't think we necessarily need to build ALL of that for every PR merge.

div72 commented 6 months ago

Alright, I'd recommend starting with adding targets for deb/rpm files in Makefile.am. We can add it to the CD to get them automatically builded then.

jamescowens commented 6 months ago

My opinion is that an appimage build is effectively equivalent to a static build in that it has all of the dependencies in the self-unpacking archive. The depends style builds for Linux are flawed and do NOT produce truly static builds. They have remaining dependencies that make their portability across distributions limited. I am in favor of doing appimage for the fallback "generic" linux case rather than the depends style static build for Linux.

jamescowens commented 6 months ago

@caraka You need to weigh in here.

APCBoston commented 6 months ago

Alright, I'd recommend starting with adding targets for deb/rpm files in Makefile.am. We can add it to the CD to get them automatically builded then.

Not sure why it would be a Makefile target? rpm and deb are just structured ways of packaging what something like make install would do into a sparkling .tar.gz; maybe just because I'm more familiar with Github Actions than autotools but my inclination was just to add GHA jobs to pack them upon release.

div72 commented 6 months ago

@APCBoston

Not sure why it would be a Makefile target?

div72 commented 6 months ago

My opinion is that an appimage build is effectively equivalent to a static build in that it has all of the dependencies in the self-unpacking archive. The depends style builds for Linux are flawed and do NOT produce truly static builds. They have remaining dependencies that make their portability across distributions limited. I am in favor of doing appimage for the fallback "generic" linux case rather than the depends style static build for Linux.

@jamescowens I hadn't checked before, the fact that depends style builds link to anything other than the libc is a bug that we should fix imo.

AFAIK AppImages are just inferior versions of static binaries. They don't get the performance benefits of inlining nor the size benefits of dead code elimination and they have to have a layer of indirection before they can be run.

APCBoston commented 5 months ago 
* We don't rely on a specific CI, so you'd have to add it to the shell scripts instead of adding them as a GHA workflows.

I have no quibble with any of your other points, but this one has me scratching my head. The repo is in Github. Github provides GHA workflows as an available tool, and this project uses them for builds already... so in what sense do we "not rely on a specific CI" when we are in fact using GHA, and what would make a GHA workflow problematic?

caraka commented 4 months ago

@caraka @div72 I'm interested in taking this one on. Jim mentioned in the discord that I should check in with the two of you.

Definitely worth taking on. I built some appimages some years ago now, and they proved to be very unreliable at the time. AppImages have come a long way since then (as have we) and I am sure that w they would play nice now.