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
[configure] Fix version checks for lablgtk and zarith #13049
[configure] Fix version checks for lablgtk and zarith #13049
Conversation
Nix needs a bump:
|
I opened a PR: NixOS/nixpkgs#98164 |
if vi < [3; 0; 0] then | ||
try | ||
let vl = numeric_prefix_list v in | ||
let vn = List.map int_of_string vl in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of code is very fragile if the version does contain strings; but it is not easy to fix as string comparison will fail to handle "9" < "10"
. Only solution is to do the cleanup and vendor opam's code for version comparison.
Thanks @Zimmi48 , please push the ref update when merged. |
if zarith_version_int >= [1;10;0] then | ||
cprintf "You have the Zarith library %s installed. Good!" zarith_version | ||
else | ||
die ("Zarith version 1.10 is required, you have " ^ zarith_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is not a single version of Ubuntu nor Debian which ships such a new zarith in libzarith-ocaml-dev. The newest (in Ubuntu focal and groovy and Debian bullseye and sid) is 1.9.1. If 1.9.1 is not new enough, I'd like to request that the switch to zarith be reverted until such time as there is at least some Ubuntu/Debian version with the relevant version of zarith, ideally a stable one (Debian stable currently ships 1.7.1). You can see the newest package versions at https://packages.ubuntu.com/search?keywords=ocaml-zarith&searchon=sourcenames and https://packages.debian.org/search?searchon=names&keywords=libzarith-ocaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added this question to the next call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually we have this requirement on OCaml, as upgrading it is significantly complex; in particular it needs recompilation of all OCaml libs.
For an OCaml library I think the situation is much easier, whoever is uploading the Coq Debian package can also upload an updated zarith
easily. Or alternatively, it can be vendored easily.
@JasonGross concern is orthogonal to this PR, which is IMO of high priority for users of |
Indeed, let's merge this PR and discuss whether or not to revert both the code dependency and this check on the call next week. I would suggest splitting this PR into two commits, though, one for lablgtk and one for zarith, so that it's easier to revert if that's what we decide to do. |
Er, nevermind my suggestion about splitting the commits, I see that we'd actually still want the version check, and would just want to edit the numbers. |
Done. |
Thanks a lot @Zimmi48 , this should be ready however the windows error is a bit bizarre :S |
I see that's unrelated, so IMHO if CI passes this should be ready to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK
@coqbot: merge now |
@SkySkimmer: You can't merge the PR because some changes are requested. |
@coqbot: merge now |
try | ||
let vl = numeric_prefix_list v in | ||
let vn = List.map int_of_string vl in | ||
if vn < [3; 1; 0] then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This must be >=
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, the problem is not the comparison, but the beta version package by Debian I'm afraid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@treinen apparently the META from from sid of lablgtk3 does not contain the version = ..
line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, one has to be careful to use the right upstream tar.bz2
that contains the correct meta, or indeed tell dune to generate a meta with a git commit hash + version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the "resolved" status so that @treinen will be able to spot this discussion more easily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@treinen I see an override of build indeed; tho we can maybe see this briefly in person some of these days ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actulally you are right about old makefile
in lablgtk being not good for packagers, now the default make target just produces this:
Welcome to lablgtk Dune-based build system. Targets are
- release: build lablgtk package in release mode
- dev: build in developer mode [requires extra dependencies]
- dev-all: build in developer mode [requires extra dependencies]
- nopromote: dev build but without re-running camlp5 generation
- opam: internal, used in CI testing
- clean: clean build tree
WARNING: Packagers should not use this makefile, but call dune
directly with the right options for their distribution, see README
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the bug report against the debian package of lablgtk3, @ejgallego, this is fixed now for the latest version in sid.
Concerning the override of the build target, I was looking at 3.1.0-3, and was missing the fact that @glondu had in the meantime uploaded a new version. My bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @treinen , I will follow up in Debian BTS; I do believe having a dh_ocaml_dune
helper would be great, Dune developers would happily add some features to dune install
for example would that help debian.
We could even instruct Dune to produce Debian packages, but that would be a bit inflexible w.r.t. Debian policy IMO, at least until Dune itself is a bit more generic [then dh_dune could just ship a plugin and everything would be taken care of] Note that dune already knows install files etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes #13041 #13047
Configure is quite messy, but we will improve it once we can link it
with findlib and move to dune [that will actually allow to remove all
ad-hoc calls to
ocamlfind
in favor offindlib
code.