Thanks for the message Arnaud. Replies inline.
Arnaud Daby-Seesaram <[email protected]> writes:
Hi Jason,
Thank you for getting the ball rolling on this issue. I am not
part of
the OCaml team, but use OCaml and Rocq on a daily basis and
might join
the team soon.
If you need or want, I would be happy to review your work or
contribute
to it to help getting it merged in Guix proper in a timely
fashion.
Sounds good to me! The more eyeballs, the better.
Jason Conroy <[email protected]> writes:
It's been a while since the core OCaml packages in Guix have
seen
significant updates, so I'd like to discuss moving the dev
stack from
OCaml 4.14 to the latest release, 5.3.
[...]
Meanwhile, the OCaml package ecosystem has started to move away
from
supporting the 4.x series. In particular, recent versions of
Jane
Street packages don't support 4.x at all, and lots of packages
from
other sources depend on Jane Street code directly or
indirectly.
I agree that it makes sense to focus on 5.3 only (and soon 5.4)
---at
True, 5.4 is just around the corner. The reason I'm focusing on
5.3 here
is that the package updates have been lagging behind compiler
updates by
a few months. For example, 5.3 was released in January but
`stdcompat`
(https://github.com/ocamllibs/stdcompat) gained 5.3 compatibility
just a
couple weeks ago. In any case though, the updates for 5.3 -> 5.4
should
be pretty modest by comparison.
least until we get to an up-to-date environment. Once the
update is
done, I think it would be nice to check that core packages¹
still build
with 4.14.2 (updated from 4.14.1) until it is officially
deprecated.
¹: by core I exclude (at least) PPX-dependent packages.
I agree that ongoing 4.x support seems achievable, if we can all
agree
on a strategy.
There was a small number of package builds that I couldn't get
working
with 5.x (some single-digit number), so we'll need to discuss how
to
handle those anyway.
For the last few weeks I've been testing a branch of Guix with
updates
for OCaml 5.3, and I'd like to contribute these changes to
upstream.
Is your work available somewhere or do you plan on opening a
Pull
Request on Codeberg/sending a patch series via email? Also, do
you (or
others) know if it is possible to get an OCaml-branch, so that
QA or CI
can provide package coverage?
Right now the code is still on a private branch as it needs some
cleanup.
I will defer to maintainers on the best way to move forward, but a
branch might make sense. The diff is about 2000 LoC, and it's more
than
just updated version strings and hashes. Also, the only machines I
have
for testing are x64.
Considering the existing project goals for this fall, how do
folks
feel about including these changes in the next release?
I have not followed recent discussions about release schedules,
so I
will let others comment on this.
NB: I have also started to update the OCaml ecosystem and was
getting to
a satisfying point (but I am not there just yet). Here is
something
that I found useful after updating dune in case it can help:
setting
the DUNE_CACHE environment variable to "disabled" in an
early build
phase to avoid cache-related warnings by dune.
Thanks for the tip! Is this perhaps something that should be
tweaked in
the build system itself?
Cheers,
Jason
