similar to: [PATCH 1/2] mllib: remove spurious check_SCRIPTS from Makefile.am

This commit starts to split our massive, monolithic configure.ac file into smaller files, using the m4_include mechanism to combine them. I don't know if we should really do this, so I'm open to comments about it. However: - Our configure.ac script is 1800+ lines long, and that's pretty long. - configure.ac lacks structure; splitting it up might improve that. - From what I read,

Instead of parsing the version, try to look for the OUnit2 module within the oUnit package. Followup of commit 46bc79109bb51cfb656863da3635f1c8da5f6412. --- configure.ac | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/configure.ac b/configure.ac index 5ff151b..7a609cb 100644 --- a/configure.ac +++ b/configure.ac @@ -1135,6 +1135,7 @@ AS_IF([test

OCaml 4.02 introduced the 'bytes' type, a mutable string intended to replace the existing 'string' type for those cases where the byte array can be mutated. In future the 'string' type will become immutable. This is not the default now, but it can be forced using the '-safe-string' compile option. I tested this on Fedora 24 (OCaml 4.02) & RHEL 7 (OCaml 4.01).

On Tue, May 12, 2015 at 03:20:56PM +0200, Pino Toscano wrote: > Not actually useful, as TESTS defines the tests, and it breaks when > oUnit is not available (as it tries to build an oUnit-based unit test). > --- > mllib/Makefile.am | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/mllib/Makefile.am b/mllib/Makefile.am > index 0b43684..e363f27 100644 > ---

On Mon, May 11, 2015 at 07:22:58PM +0200, Pino Toscano wrote: > On Monday 11 May 2015 11:11:50 Richard W.M. Jones wrote: > > OUnit2 has an OUnit (v1) compatibility module. Unfortunately it > > is rather gravely broken: > > https://forge.ocamlcore.org/tracker/?func=detail&aid=1392&group_id=162&atid=730 > > > > Since there is no new release fixing this,

It will be used for the OCaml unit tests. --- configure.ac | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/configure.ac b/configure.ac index e0fb481..e360bbb 100644 --- a/configure.ac +++ b/configure.ac @@ -1120,6 +1120,7 @@ AS_IF([test "x$OCAMLC" != "xno"],[ ]) OCAML_PKG_gettext=no +OCAML_PKG_oUnit=no AS_IF([test "x$OCAMLC" != "xno"],[ #

OUnit2 has an OUnit (v1) compatibility module. Unfortunately it is rather gravely broken: https://forge.ocamlcore.org/tracker/?func=detail&aid=1392&group_id=162&atid=730 Since there is no new release fixing this, it's easier to switch to using OUnit2 for unit tests. --- .gitignore | 2 +- README | 2 +- mllib/JSON_tests.ml | 56

On Thu, Aug 03, 2017 at 06:08:24PM +0200, Pino Toscano wrote: > But I guess I have no chance to change the current patch (even adding > a test using asserts, instead of oUnit, for which I still did not get > a reason why a new test using it would be unacceptable), so ... Fewer dependencies make the code easier for others to consume, and that's especially true when (like oUnit) those

On Wednesday, 19 July 2017 16:33:39 CEST Richard W.M. Jones wrote: > On Wed, Jul 19, 2017 at 02:29:33PM +0200, Pino Toscano wrote: > > On Wednesday, 19 July 2017 14:21:51 CEST Richard W.M. Jones wrote: > > > On Wed, Jul 19, 2017 at 12:57:08PM +0200, Pino Toscano wrote: > > > > Would it be possible to use oUnit too? > > > > > > I'm not clear on

On Wednesday, 19 July 2017 14:21:51 CEST Richard W.M. Jones wrote: > On Wed, Jul 19, 2017 at 12:57:08PM +0200, Pino Toscano wrote: > > Would it be possible to use oUnit too? > > I'm not clear on what benefit oUnit gives us which is worth the extra > dependency it pulls in. I was referring to OUnit2, which we already have an optional dependency for almost all the OCaml

As I'm now working through the enormous virt-v2v/virt-p2v bug list, we need a high quality set of tests to ensure that we don't accidentally regress some old OS/hypervisor combination while making changes. The test cases are going to be huge, so we cannot possibly distribute them in libguestfs. Furthermore many of them have licensing problems which means we cannot redistribute them at

We ship our own copy of it, so we do not need the external version. (Also, the latest upstream version of ocaml-libvirt was already not usable to build the test harness of v2v.) --- m4/guestfs-ocaml.m4 | 4 ---- 1 file changed, 4 deletions(-) diff --git a/m4/guestfs-ocaml.m4 b/m4/guestfs-ocaml.m4 index fea11a334..d3c4bd645 100644 --- a/m4/guestfs-ocaml.m4 +++ b/m4/guestfs-ocaml.m4 @@ -145,7

Since commit d5b6f1df5ff2d387a5dfc89b8316c0dff67ce2c9, the daemon requires ocaml-hivex; OTOH, nothing checks it is actually available, so the build of the daemon will fail with a semi-cryptic error about the lack of a directory in the OCaml install prefix. As fix, check for the presence of the hivex module at build time, failing earlier if not present. The check is performed only when the daemon

Would it be possible to use oUnit too? -- Pino Toscano

Two (not related to each other) refactorings: Patches 1-12 split configure.ac into smaller files using the m4_include mechanism. Patches 13-15 split out parts of guestfs.pod (ie. guestfs(3)) into three new manual pages: guestfs-hacking(3) - how to extend and contribute to libguestfs guestfs-internals(3) - architecture and internals guestfs-security(3) - security and CVEs Patch 16 is a

Per my previous email: https://www.redhat.com/archives/libguestfs/2017-September/msg00203.html I'd like to talk about requiring a more modern version of the OCaml compiler. These commits show some of the code changes which would be possible with OCaml >= 3.12 [which it turns out we already require by accident] and also with OCaml >= 4.02. The latter is my favoured option. Rich.

Miscellaneous refactoring, but the main one is to rename mllib/ as common/mltools/ Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2017-October/msg00183.html v2: - Adds back the Debian test, but simplified. - Adds tests on Fedora & Debian. Rich.

On Wed, Aug 02, 2017 at 03:01:53PM +0200, Pino Toscano wrote: > On Wednesday, 2 August 2017 13:52:06 CEST Richard W.M. Jones wrote: > > I think you're suggesting this: > > > > let m = PCRE.exec re "ccaaaabb" in > > if PCRE.matches m then ( > > let whole = PCRE.sub m 0 in > > Not really, my suggestion was to have a separate object

On Friday, 4 August 2017 10:01:28 CEST Richard W.M. Jones wrote: > You asked me to reply to some other points (copied from > https://www.redhat.com/archives/libguestfs/2017-July/msg00189.html): > > > Sure. OTOH, we already do use oUnit2, so these reasonings were already > > discussed in the past, and (considered we have tests based on oUnit2) > > deemed not a problem.