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

[Yishuai Li]

>   - When there are multiple files for multiple build flavors, can one
>     build them without colliding?   Or is this really a dune issue?
>
>
> I'm not sure I understand your question: opam is really a "package manager", so the question is not really *building* the software in multiple flavors, but rather *installing* it.
>
> It is possible to have several opam files at the root of the same repository. They will correspond to different packages using the same source tree, for example because the software has been split into several packages (a library may be distributed using several packages representing different features set o the library...). But if these packages are installed simultaneously, then it's just like with "make install": they need to install a different set of files. Otherwise, they are conflicting, and this should be part of a "conflict" clause of the opam files.
>
> In the case of unison, we have several options:
> 1- have two packages "unison-cli" and "unison-gui", both installing the executable "unison", and declare the two packages in conflict. The user will have to choose between the two packages when typing "opam". The problem is perhaps that there is no "canonical" package for unison.
> 2- same as 1-, but with two different names for the executable. The user can install both packages, but once installed, she will have to type two different commands depending on whether she wants to use the version with the GUI or not: this is not the same behavior as with "make install" and thus I don't really like this solution.
> 3- use only one package, but with an optional dependency on lablgtk. The package will be built with two different configuration depending on whether lablgtk is installed, and an upgrade of lablgtk will automatically trigger a rebuild of unison. The disadvantage is that a user willing to install unison with the gui will type "opam install unison", but will not have the gui installed because lablgtk will not be installed by default; this can be confusing.
> 4- same as 3-, but with a pseudo-package "unison-gui" (i.e., without any code), with a dependency on both "unison" and "lablgtk", so that installing "unison-gui" will make sure the GUI is enabled. This is somewhat less confusing than 3-, because a user can install an actual package that says "I want unison with its GUI".

I agree that 4- is the right direction to go.
In PR #671 I've just unlinked OPAM from Dune, but have less confidence
in writing the build rules myself.
JH do you feel like writing the Makefile-based rules to make the PR
ready to merge?

Yishuai