* [PATCH 2/2] tools/ocaml: Default to useful build output
@ 2020-07-18 3:32 Elliott Mitchell
2020-07-20 8:25 ` Christian Lindig
2020-07-20 8:38 ` Christian Lindig
0 siblings, 2 replies; 6+ messages in thread
From: Elliott Mitchell @ 2020-07-18 3:32 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson, christian.lindig, wl, dave
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(-)
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:
--
2.20.1
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] tools/ocaml: Default to useful build output
2020-07-18 3:32 [PATCH 2/2] tools/ocaml: Default to useful build output Elliott Mitchell
@ 2020-07-20 8:25 ` Christian Lindig
2020-07-20 8:38 ` Christian Lindig
1 sibling, 0 replies; 6+ messages in thread
From: Christian Lindig @ 2020-07-20 8:25 UTC (permalink / raw)
To: Elliott Mitchell, xen-devel@lists.xen.org
Cc: Ian Jackson, wl@xen.org, dave@recoil.org
________________________________________
From: Elliott Mitchell <ehem+xen@m5p.com>
Sent: 18 July 2020 04:32
To: xen-devel@lists.xen.org
Cc: Ian Jackson; wl@xen.org; Christian Lindig; dave@recoil.org
Subject: [PATCH 2/2] tools/ocaml: Default to useful build output
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(-)
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:
--
2.20.1
--
Acked-by: Christian Lindig <christian.lindig@citrix.com>
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] tools/ocaml: Default to useful build output
2020-07-18 3:32 [PATCH 2/2] tools/ocaml: Default to useful build output Elliott Mitchell
2020-07-20 8:25 ` Christian Lindig
@ 2020-07-20 8:38 ` Christian Lindig
2020-07-20 9:00 ` Paul Durrant
2020-07-20 9:36 ` Edwin Torok
1 sibling, 2 replies; 6+ messages in thread
From: Christian Lindig @ 2020-07-20 8:38 UTC (permalink / raw)
To: Elliott Mitchell, xen-devel@lists.xen.org
Cc: Ian Jackson, Edwin Torok, wl@xen.org, dave@recoil.org
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH 2/2] tools/ocaml: Default to useful build output
2020-07-20 8:38 ` Christian Lindig
@ 2020-07-20 9:00 ` Paul Durrant
2020-07-20 9:24 ` Christian Lindig
2020-07-20 9:36 ` Edwin Torok
1 sibling, 1 reply; 6+ messages in thread
From: Paul Durrant @ 2020-07-20 9:00 UTC (permalink / raw)
To: 'Christian Lindig', 'Elliott Mitchell', xen-devel
Cc: 'Ian Jackson', 'Edwin Torok', wl, dave
> -----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] tools/ocaml: Default to useful build output
2020-07-20 9:00 ` Paul Durrant
@ 2020-07-20 9:24 ` Christian Lindig
0 siblings, 0 replies; 6+ messages in thread
From: Christian Lindig @ 2020-07-20 9:24 UTC (permalink / raw)
To: 'Elliott Mitchell', xen-devel@lists.xen.org, paul@xen.org
Cc: Ian Jackson, Edwin Torok, wl@xen.org, dave@recoil.org
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
________________________________________
From: Paul Durrant <xadimgnik@gmail.com>
Sent: 20 July 2020 10:00
To: Christian Lindig; 'Elliott Mitchell'; xen-devel@lists.xen.org
Cc: Ian Jackson; Edwin Torok; wl@xen.org; dave@recoil.org
Subject: RE: [PATCH 2/2] tools/ocaml: Default to useful build output
> -----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] tools/ocaml: Default to useful build output
2020-07-20 8:38 ` Christian Lindig
2020-07-20 9:00 ` Paul Durrant
@ 2020-07-20 9:36 ` Edwin Torok
1 sibling, 0 replies; 6+ messages in thread
From: Edwin Torok @ 2020-07-20 9:36 UTC (permalink / raw)
To: ehem+xen@m5p.com, Christian Lindig, xen-devel@lists.xen.org
Cc: Ian Jackson, Andrew Cooper, wl@xen.org, dave@recoil.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-07-20 9:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-07-18 3:32 [PATCH 2/2] tools/ocaml: Default to useful build output Elliott Mitchell
2020-07-20 8:25 ` Christian Lindig
2020-07-20 8:38 ` Christian Lindig
2020-07-20 9:00 ` Paul Durrant
2020-07-20 9:24 ` Christian Lindig
2020-07-20 9:36 ` Edwin Torok
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.