Hi Jason, Jason Conroy <jcon...@tscripta.net> writes:
> Arnaud Daby-Seesaram <ds...@nanein.fr> writes: > >> 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. That is a good point, indeed. > In any case though, the updates for 5.3 -> 5.4 should be pretty modest > by comparison. Agreed. >> 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. +1 >> 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? Yes, I added a phase before "build" in the dune-build-system (similarly to the `ocaml-findlib-environment' phase in the ocaml-build-system). I used an environment variable rather than adding "--cache=disabled" to the invocation of dune because some tests ran "dune exec" by hand. Best regards, -- Arnaud
signature.asc
Description: PGP signature
