-
Notifications
You must be signed in to change notification settings - Fork 217
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
Publish the library files as an artifact after builds #3953
Comments
@vanillajonathan if you'd be interested, I think this would be quite helpful. The goal would be to have those files published on each release in the release assets (e.g. at the bottom here: https://github.com/PRQL/prql/releases/tag/0.10.1) |
We use our |
Great questions — thanks for thinking through it. I think two main options:
(Possibly there's a third option of "split up the parts that are common across both", but my guess is that will be much easier after making it work with one of those) Your call on what to try. If you're not sure, I might try and get it working with the copy-paste, and then if you find you don't need to change anything, integrate them into a single action. Then I think we'll have to add it to this so it publishes on release.
The one learning on caching is here — it's better to build for everything rather than only
@eitsupi would you know whether we should be building this using (if we don't use |
Since both gnu ABI and musl ABI may be used, don't we need to build both? I have confirmed that prqlr works with prql-compiler built with only musl, whether R is gnu or musl, so I only use musl for binary builds, but I am not sure if this is true in all cases. |
When building using the gnu target, we can build binaries that can be used by many clients by lowering the Ubuntu version of the runner of CI as much as possible, but this will not work for distributions that only use musl, such as Alpine Linux. If we build using the musl target, it may not work if the program being linked uses the gnu ABI. |
Thanks a lot @eitsupi , that makes sense. Given the immediate need is for dotnet, I think we could consider only having for |
I think it makes sense to update the existing action and make the target name an argument so that we can build something other than |
Hi @max-sixty, will take a look to the next steps to build .NET bindings probably tomorrow. |
FYI @eitsupi I looked at doing this — but there were too many differences, such as the path of the package. I started a conversation to try and align names to make things a bit more similar, but there's enough that's different that copy&paste&edit was easier |
What's up?
Regarding ongoing discussions on Discord on the pros/cons of having a mono-repo vs a repo dedicated for each language binding, we came to a point where the lack of proper packaging of the library files (
.dll
,.dylib
and.so
) is a major impediment when executing the "repo by language bindings" strategy.This issue is to track progress on packaging library files during builds and make them available for other repos.
The text was updated successfully, but these errors were encountered: