| Message ID | 20200718033242.GB88869@mattapan.m5p.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] Partially revert "Cross-compilation fixes." | expand |
> Time for a bit of controversy.
OCaml outside Xen has moved to a different model of building based on dune which is fast, declarative and reliable. The OCaml xenstore is stagnating because nobody with OCaml experience wants to touch it anymore. It would be beneficial for the health of the OCaml xenstore to split it out such that it could be worked on independently. You might argue that Make is still appropriate for building OCaml projects but the OCaml community has moved through several build systems, starting from Make, and learned the hard way that this is not an easy problem. After years of more-or-less successful build system the consensus is that dune is right one and it has resulted in combination with the Opam package manager the ecosystem to flourish. Alternatively, it would be possible to move OCaml xenstore to dune within the Xen tree but it would create a dependency on it.
-- C
> -----Original Message----- > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Christian Lindig > Sent: 20 July 2020 09:39 > To: Elliott Mitchell <ehem+xen@m5p.com>; xen-devel@lists.xen.org > Cc: Ian Jackson <Ian.Jackson@citrix.com>; Edwin Torok <edvin.torok@citrix.com>; wl@xen.org; > dave@recoil.org > Subject: Re: [PATCH 2/2] tools/ocaml: Default to useful build output > > > > > Time for a bit of controversy. > > OCaml outside Xen has moved to a different model of building based on dune which is fast, declarative > and reliable. The OCaml xenstore is stagnating because nobody with OCaml experience wants to touch it > anymore. It is still the default. Would you suggest that we change this and make C xenstored the default for 4.15, deprecating oxenstored with a view to subsequently purging it from the tree in the 4.16 dev cycle? Paul > It would be beneficial for the health of the OCaml xenstore to split it out such that it > could be worked on independently. You might argue that Make is still appropriate for building OCaml > projects but the OCaml community has moved through several build systems, starting from Make, and > learned the hard way that this is not an easy problem. After years of more-or-less successful build > system the consensus is that dune is right one and it has resulted in combination with the Opam > package manager the ecosystem to flourish. Alternatively, it would be possible to move OCaml xenstore > to dune within the Xen tree but it would create a dependency on it. > > -- C
I think this would at least force a clean-up and open the project to wider set of OCaml developers. This might lead to a situation where the OCaml xenstore is not readily available for the consumers of Xen and I don't know who wants it how much. But I would prefer a situation where the OCaml xenstore can be built against a system with Xen libraries installed rather than only within the Xen tree. This would help to modernise the OCaml xenstore code base not just in terms of the build system but tackle long-standing problems like improving the code around select/poll which is inefficient. -- C
On Mon, 2020-07-20 at 10:38 +0200, Christian Lindig wrote: > > Time for a bit of controversy. > > OCaml outside Xen has moved to a different model of building based on > dune which is fast, declarative and reliable. The OCaml xenstore is > stagnating because nobody with OCaml experience wants to touch it > anymore. It would be beneficial for the health of the OCaml xenstore > to split it out such that it could be worked on independently. AFAIK there are 2 unstable interfaces used by oxenstored, decoupling it would make the version of oxenstored more independent from the version of hypervisor: https://andrewcoop-xen.readthedocs.io/en/docs-devel/misc/tech-debt.html#remove-xenstored-s-dependencies-on-unstable-interfaces IIUC this would also allow some code to be droped from the hypervisor where oxenstored is the last user of the unstable interface. > You might argue that Make is still appropriate for building OCaml > projects but the OCaml community has moved through several build > systems, starting from Make, and learned the hard way that this is > not an easy problem. After years of more-or-less successful build > system the consensus is that dune is right one and it has resulted in > combination with the Opam package manager the ecosystem to flourish. > Alternatively, it would be possible to move OCaml xenstore to dune > within the Xen tree but it would create a dependency on it. I'd welcome a Dune based build-system. The current Makefile based build-system doesn't handle dependencies correctly for incremental development: I often have to run 'make clean' in order to successfully build xenstored after changing an .ml file, otherwise the linker fails with 'inconsistent assumptions over interface', indicating that Make hasn't rebuilt something that it should have. (For those unfamiliar with this issue, see the 'Motivation' section in https://nicolaspouillard.fr/ocamlbuild/ocamlbuild-user-guide.html) It also lacks generation of .merlin files (for editor integration, e.g. Vim or Emacs), which you get for free with Dune. We could still retain a Makefile as an entrypoint that launches Dune with appropriate flags, which aside from adding a build requirement on Dune wouldn't require changes to package building. I think a nice way forward here would be to try to write a minimal binding to gnttab to replicate https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=38eeb3864d in OCaml, this would both demonstrate the benefits of Dune (making contribution easier), and reduce technical debt within Xen. Best regards, --Edwin
diff --git a/tools/ocaml/Makefile.rules b/tools/ocaml/Makefile.rules index a893c42b43..abfbc64ce0 100644 --- a/tools/ocaml/Makefile.rules +++ b/tools/ocaml/Makefile.rules @@ -1,17 +1,20 @@ ifdef V - ifeq ("$(origin V)", "command line") - BUILD_VERBOSE = $(V) - endif + ifeq ("$(origin V)", "command line") + BUILD_VERBOSE = $(V) + endif +else + V := 1 + BUILD_VERBOSE := 1 endif ifndef BUILD_VERBOSE - BUILD_VERBOSE = 0 + BUILD_VERBOSE := 0 endif ifeq ($(BUILD_VERBOSE),1) - E = @true - Q = + E := @true + Q := else - E = @echo - Q = @ + E := @echo + Q := @ endif .NOTPARALLEL:
While hiding details of build output looks pretty to some, defaulting to doing so deviates from the rest of Xen. Switch the OCAML tools to match everything else. Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com> --- Time for a bit of controversy. Presently the OCAML tools build mismatches the rest of the Xen build. My choice is to default to verbose output. While some may like beauty in their build output, function is far more important. If someone wants to take on the task of making Xen's build output consistently beatiful, invite them to do so. Then call the police and tell them you're being robbed. --- tools/ocaml/Makefile.rules | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)