Skip to content
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

Revise libsingular_jll handling #735

Open
fingolfin opened this issue Nov 24, 2023 · 3 comments
Open

Revise libsingular_jll handling #735

fingolfin opened this issue Nov 24, 2023 · 3 comments

Comments

@fingolfin
Copy link
Member

  • we probably should specify the version in Project.toml via =VERSION to pin a specific version, thus avoiding issues caused by Singular.jl and libsingular-julia not being in sync
  • the code for re-compiling the libsingular code should be disabled when Singular.jl is not dev'ed
@fingolfin
Copy link
Member Author

To elaborate:

We recently had trouble because we update the libsingular_julia_jll patch version, but did not immediately update Singular.jl. As a result people who did Pkg.update() got the new libsingular_julia_jll but with an older Singular.jl that did not expect it. As a result, Singular.jl decided to compile its own version of libsingular_julia_jll which however failed for people who don't have cmake installed. As a result, for these developers Oscar.jl was broken: bad.

I see these options to address it (note that they could also be combined)

  1. lock the version of libsingular_julia_jll in Project.toml to an exact match, i.e., =VERSION in the compat section. This avoids the problem completely, but has the drawback that we can't update libsingular_julia_jll seperate from Singular.jl -- though IMHO that's a minor loss
  2. modify the code which tries to recompile libsingular_julia_jll. Some alternatives for that:
    1. only run it when Singular.jl has been "dev'ed"
    2. only run it when cmake is present
    3. only run it when the version of libsingular_julia_jll is <= the version in the compat (i.e. assume for a "too new" libsingular_julia_jll that it is intentionally different)

@benlorenz
Copy link
Member

benlorenz commented Nov 28, 2023

Regarding option 1: I just did exactly such an update for libpolymake_julia, rebuilding it (with a new version due to the compat) to adapt to the new libcxxwrap_julia version for julia nightly (JuliaPackaging/Yggdrasil#7725). This would not be possible anymore without a Singular.jl release. Edit: Similarly for rebuilding against a new Singular_jll version.

I think it would be reasonable to have the automatic compilation opt-in only, i.e. if whatever conditions are met (e.g. dev + cmake + ...) print a warning and suggest setting some environment variable / Preferences.jl entry. Only if this is set run the automatic compilation.

@ederc
Copy link
Member

ederc commented Nov 28, 2023

I support to do the exact match of libsingular_julia_jll in Project.toml, any update should give us at least a minor release of Singular.jl. IMHO this would help speeding up the workflow for people working on Singular stuff in Oscar.jl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants