-
Notifications
You must be signed in to change notification settings - Fork 33
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
Merge libsingular-julia
into this report and set up a system where it automatically is used to replace the JLL if appropriate
#600
Comments
This is my workflow. Can you comment on exactly what would change in the loop?
|
Assuming no changes in
|
(It would also make it easy to track coverage of the C++ code, see issue #224, but that's a minor side concern) |
Reminder to myself: to get the tree hash e.g. the
|
7 tasks
Resolve by #639 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I propose that we put the code (and history) https://github.com/oscar-system/libsingular-julia back into this repository; but with a slight twist that I'll explain shortly.
The motivation is that often fixes require changes both in
Singular.jl
and inlibsingular-julia
. This is more convenient if they can be put into a single PR. Of course in practice to deploy these fixes we then still need to update thelibsingular_julia_jll
. And to test these changes one has to follow a carefully choreographed dance with overrides and whatnot.But instead, I suggest to adapt a technique I am successfully using for GAP.jl. It works something like this:
GAP_pkg_juliainterface_jll
) I track which source code was used to produce the JLL. That could be a git tree hash of the relevant source directorylibsingular_julia_jll
, check if it references the same source code as is bundled, by comparing the git tree hash or whatever. If they match, just use the JLL. But if they do not match... compile the source code (i.e., invoke cmake) and load that. Here is the relevant function for that from GAP.jl:This has simplified my life working on the C code in GAP.jl drastically. I now edit the C/C++ code with impunity in tandem with the Julia code. Once this works on my computer, I can submit it as a PR, and CI passes. Once all is good, I can merge the PR and only then do I update the JLL.
The one drawback of my current setup has is that I should add a CI test that prevents me from making a release if the JLL is outdated. (E.g. it could be a regular CI test that fails even on the PR, but I could ignore it on PRs. Or the JLL could be updated while the PR is approve but not yet merged, whatever, these are minor details).
All in all this is not hard to pull off but IMHO would be a great benefit for Singular.jl. At least for me this is much easier to work than dealing with JLL overrides; it is 100% automatic. No matter how good our override scripts are, they still require more manual work and offer more chances for me to screw up using them correctly...
(Perhaps it would also be useful for Polymake.jl, @benlorenz ?)
The text was updated successfully, but these errors were encountered: