[new release] flint (0.4.2)

[bobot]

Stub of the C library Flint3

• Project page: https://github.com/bobot/ocaml-flint

CHANGES:

• Fix compilation (@bclement-ocp)

[jmid]

Thanks!

A couple of questions and remarks:

Out of curiosity: I see antic, arb, and calcium are deprecated as they have been incorporated into flint. For how long do you plan to release forwarding releases of these? (I have archiving in mind) Perhaps adding a post-messages entry could encourage clients to update their dependencies? 🤔

Platform-wise it looks like conf-flint on Alpine, Centos, and FreeBSD could use a hand (...but probably as a separate PR that this one could benefit from)

There are runtest failures on arm32 and ppc64. What do you make of these?

Finally, would you consider adding an x-maintenance-intent entries?
https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md

[bobot]

Perhaps adding a post-messages entry could encourage clients to update their dependencies? 🤔

There is not a lot of users of this library, so next version those deprecated package will be removed. Dune perhaps already warn that they are deprecated.

Platform-wise it looks like conf-flint on Alpine, Centos, and FreeBSD could use a hand

Normally alpine should be fixed. On the other hand the package doesn't exists anymore in centos, and doesn't exists in freebsd. I don't want to forbid to install the package on this distribution since a user can install the C library manually. Perhaps there is some ci-dont-test: {os = freebsd}?

For the segfault on arm32 and ppc, I'm in the process of changing the way the binding is written. So it could disappear then. Should I do something for those platform in the mean time?

[jmid]

There is not a lot of users of this library, so next version those deprecated package will be removed. [,,,]

OK, thanks for sharing!

Platform-wise it looks like conf-flint on Alpine, Centos, and FreeBSD could use a hand

Normally alpine should be fixed. On the other hand the package doesn't exists anymore in centos, and doesn't exists in freebsd. I don't want to forbid to install the package on this distribution since a user can install the C library manually.

Good point!

Perhaps there is some ci-dont-test: {os = freebsd}?

We cannot prevent the CI run but we can silence the CI-error on FreeBSD: 🤷

x-ci-accept-failures: ["freebsd-14.3"]

For the segfault on arm32 and ppc, I'm in the process of changing the way the binding is written. So it could disappear then. Should I do something for those platform in the mean time?

If the packages work reasonably on arm32 and ppc64 except for test suite corner cases, we could just disable runtest on those platforms:

    "@runtest" {with-test & arch != "arm32" & arch != "ppc64"}

Alternatively, we could just disable the packages entirely on the platforms to prevent potential users from chasing segfault ghosts: 👻

available: arch != "arm32" & arch != "ppc64"

[bobot]

The segfault in arm32 was due to flintlib/flint#2521

[bobot]

@jmid The last problems are just missing existing package for flint 3.* .

[jmid]

I can see your points:

• flint is not available as a MinGW Cygwin package, so we instead just use the Cygwin package. Even though that may make CI happy (actually it still fails!) that's not the way to go, because the resulting executable will then require cygwin1.dll contrary to MinGW expectations
• the MSYS2 fix is fair enough. It is 64-bit only, but MSYS2 doesn't offer a 32-bit package

[bobot]

Yes the cygwin package is outdated: https://cygwin.com/packages/summary/flint-src.html . I hope someone will update it. The process to update the package was not straightforward at first glance and msys2 seems a lively alternative.

[jmid]

Thanks, this is shaping up nicely! 😃

I've just committed a suggestion to adjust the Windows Cygwin cases.

I'll let the CI complete, expecting Cygwin-MinGW and opam-2.0 failures and then merge.

[bobot]

Thank you a lot for your help!