[Unison-hackers] dune and opam issues: a summary of my fuzzy understanding

[Greg Troxel]

Jacques-Henri Jourdan <jacques-henri.jourdan at cnrs.fr> writes:

>> JH do you feel like writing the Makefile-based rules to make the PR
>> ready to merge?
>
> Sure. But before doing that, let's wait for a few days to see if
> everyone agrees this is the way to go.

And I don't think we need to have one PR.  I am inclined to fix
separable things in chunks, and we already have two things that are
agreed, so I just merged the maintainer change and closed the issue
about it.

> Also, there is another question to answer: should we streamline the
> dune-project file, given that we no longer use it to generate opam
> files. AFAICT, much of the information there is only used for
> generating opam files. This include synopsis, descriptions, license,
> authors, maintainers and dependencies.

I am not at all sure we should do either of those things, because I
think the future of what we are doing about opam is quite uncertain.

I am not at all opposed to dune-based builds working, and I don't have a
handle on the set of systems where

  ocaml works and unison makefiles work
  opam build of unison with make would work
  opam build of unison with dune works
  dune build of unison works

My leaning is to let opam/dune-world people maintain the dune/opam
things, assuming there are people that want to follow along and do that.
Right now we have dune builds in CI, but the platform coverage of CI is
very poor, and the future of unison CI is uncertain.

There was a comment earlier about what was the set of systems and CPU
types that unison targets.  I don't immediately see anything restrictive
about opam and dune, beyond needing ocaml which of course unison does
anyway.  So is there an argument that there is no portability loss?

Can one build dune and opam with ocal 4.08 (and 4.09-4.13)?  I know it
works with 4.14 on my system, NetBSD 9 amd64.

Related, how does the broader ocaml world deal with  "Laggard Term
Stable" packaging systems that intentionally ship old code, but have
users that somehow expect to run new code?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20221116/35b62cae/attachment.asc>