New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support binary prebuilt for main platforms? #314
Comments
@xaljer good idea, but since it's a single developer project, I don't have the bandwidth to do it. Unless you want to help, I can't do it and would rely on distribution's packaging efforts. |
Perhaps providing a Dockerfile or others to easily build via docker could be an option?
although it may not work on 'vanilla' Oracle linux, and it also fails to build/install/package properly.. (I just roll my own package with the binaries I need). |
@smhc This is interesting, I'm just wondering how do you use the docker image? Is it just building the package itself or using Bear from the image? I would like to highlight that there are OS packages available for Bear. |
I am simply extracting the executables out of the image/container after it has finished building. I doubt bear would work very well in a docker container on external processes due to the use of LD_PRELOAD etc. Note the build fails due to ctest errors etc - but it at least gives me the binaries. Using a Dockerfile with docker allows reproducible builds on clean environments without needing to install dependencies locally. It's an ideal way of publishing build procedures that are reproducible by others. You'd probably want to use Ubuntu as the base. It might be a good idea to have that OS package link in the README, building bear is now quite involved. Unfortunately I don't see any 3.0.0 packages that I can make use of. |
I have copied the link from the README file. :) Yes, OS packaging are catching up with a delay of a few months. I've provided an INSTALL file with build instructions and OS package dependency lists for a few distros. (I've found this is actually more than other software do to support users.) I am hesitant to put Docker files into the repo if I can't validate them in a CI. To back to the original topic of this ticket. Do you know if GitHub action can use docker to pre-build packages and publish the artefacts? Could you help me to set that up? |
Yes I think it's quite easy. I created a github docker workflow (just used the default): And a basic Dockerfile to build: I'm not sure where the artefacts are supposed to be pushed to and what artefacts you'd want. The image itself probably isn't that useful given it's unlikely bear would work containerised. But I suppose people could take the image and use both bear and gcc from it to compile their code to and generate a compile_commands.json. You may also want to use a newer build based Dockerfile that removes all the compile time dependencies and just leaves you with the final binaries. |
Woo, that's looks easy then. And I agree, we shall publish the binaries not the whole docker image. (Maybe can use the CMake package functionality.) I think the workflow shall be executed on tags (I create releases from tags) and the release list has a place to hold the artefacts. That will probably needs some tool (github cli?) to upload. |
The existing CI job is already building bear on ubuntu and could publish a release - it doesn't really need docker for that, does it? I made a small change to the Dockerfile to fix some interactivity issues but it likely needs a re-write. I'm not sure of the best practice of getting files out of a build. I've always just created a container and used 'cp', similar to : https://unix.stackexchange.com/questions/331645/extract-file-from-docker-image Another option is to create an image with bear compiled, and then do the 'package install' as part of a container run with a mount such that it gets installed on a volume outside of the container. It also needs an actual package creation step - I'm not aware of what this would be. |
Fyi I added package creation and extraction, as well as storing the artefacts. It still needs work to build multiple platforms (different Dockerfiles) and the tie it into the release. |
We have a few options here...
|
I think static executables are preferred if there are esoteric dependencies. At least for releases on the github release area. I'm no packaging expert - but I do like the way clangd is released. You simply unzip it and it can find the dependent 'include' files relative to the clangd binary. This way it can be unzipped anywhere and work ok. I'm not sure how the various packagers put it together however. It'd be nice if bear worked like this and didn't require a wrapper script to specify all the --interceptor etc options to find the right locations. Given that bear users have a high chance of being clangd users it makes sense to follow their model. |
appimage is also a good portable format to distribute software. neovim use appimage. |
I've also seen many releases build against https://musl.libc.org/ for static binaries. It greatly increases the portability across different linux systems. |
I would vote for the "static link everything" solution, or build everything from source For some reason, I have to use an ubuntu 16.04 as my dev machine,which doens't meet the dependency requriment. If "static link everything" is optional, I could build the binay in an ubuntu 20.04 docker, and copy the exec file out. And, if possible, I thought "build everything from source" will be a much more portable solution. |
+1 for static single binary executable releases for each platform like in: |
@jacknicklenson happy to accept PR to make that happen. |
Hello, thanks for the great project! |
No description provided.
The text was updated successfully, but these errors were encountered: