Replace strange $TEST_FUNCTIONS variable/expansion thing with
something more like what we use in nbdkit, a simple tests/functions.sh
script that gets sourced into each test script.
Update the common submodule to get:
commit 8137d47d0e654065391151eb275e3b64f230f6f5
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Thu Feb 13 11:13:55 2025 +0000
mlcustomize, mltools: Replace $TEST_FUNCTIONS
TEST_FUNCTIONS is being removed from libguestfs and guestfs-tools (it
was removed from virt-v2v a while back). Make the same adjustment in
the common submodule.
(and some other commits which are not relevant to libguestfs)
Run this command across the source:
perl -pi.bak -e 's/(20[012][0-9])-20[12][012]/$1-2023/g' `git ls-files`
and remove changes to po{,-docs}/*.po{,t} (these will be regenerated
later when we run 'make dist').
With the Weblate adoption, we let it update the po files from the
catalog template. The po4a behaviour of extracting the template,
merging the existing translations, and creating the translated PODs at
once is problematic. Hence, split the extraction and the translated POD
generation in two.
Use po4a-gettextize to extract the catalog template only, not doing it
anymore automatically at each build. There is no more need for a
po4a.conf file.
Use po4a-translate to create translated PODs from the po files, keeping
the fixup of the generated files (to avoid spurious =encoding, etc).
Add a silent rule to hide the po4a-translate command lines by default.
These changes also allow us to get rid of the POD existance checks with
associated error message pointing to the update-po rule. Now each
translated POD file is generated because of make dependency, and it
depends only on its po file.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
As proposed in the Debian bug #946594 [1], the implicit .cmi/.cmo/.cmx
dependencies are tied to files in the source directory only, and thus
they break when either the .ml or the .mli files are in the build
directory. Since there is already VPATH set up by automake, rely on it
to locate the right source.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946594#36
Solution proposed by Vincent Danjean, thanks!
This reverts commit 802c5d2055 in this
file.
Here is an example of a failure with the previous dependency
calculation:
$ make -j5
make: Entering directory '/home/rjones/d/libguestfs/common/mlstdutils'
OCAMLOPT guestfs_config.cmx
CC libmlstdutils_a-dummy.o
OCAMLOPT libdir.cmx
OCAMLCMI stringMap.cmi
OCAMLCMI stringSet.cmi
OCAMLCMI guestfs_config.cmi
OCAMLCMI std_utils.cmi
OCAMLC guestfs_config.cmo
OCAMLC libdir.cmo
OCAMLC stringMap.cmo
OCAMLC stringSet.cmo
OCAMLOPT stringMap.cmx
OCAMLOPT stringSet.cmx
OCAMLOPT std_utils.cmx
OCAMLC std_utils.cmo
ocamlfind ocamlc -package str,unix -I . -a guestfs_config.cmo libdir.cmo stringMap.cmo stringSet.cmo std_utils.cmo -o mlstdutils.cma
ocamlfind ocamlopt -package str,unix -I . -a guestfs_config.cmx libdir.cmx stringMap.cmx stringSet.cmx std_utils.cmx -o mlstdutils.cmxa
AR libmlstdutils.a
File "_none_", line 1:
Error: Files std_utils.cmx and guestfs_config.cmx
make inconsistent assumptions over interface Guestfs_config
make: *** [Makefile:2523: mlstdutils.cmxa] Error 2
make: Leaving directory '/home/rjones/d/libguestfs/common/mlstdutils'
What seems to be happening is that there is a rule:
std_utils.cmx : guestfs_config.cmi guestfs_config.cmx [...]
In this case, make chose to build guestfs_config.cmx and
guestfs_config.cmi in parallel (see the first 5 rules above). However
building guestfs_config.cmx also creates guestfs_config.cmi
(implicitly - this is not expressed in make dependencies, and make
doesn't "know" that guestfs_config.cmi has already been created).
Unfortunately the OCaml compiler doesn't create output files
atomically. Worse than that, it creates an intermediate version of
the output file, reads it back and then creates the final version. It
seems if the build of std_utils.cmi reads this intermediate version.
In any case, Std_utils sees the wrong hash of the Guestfs_config
module.
The above only happens where we have a *.ml file without a
corresponding *.mli file. That is because if there is a *.mli file,
ocamldep generates slightly different dependencies:
guestfs_config.cmx [...] : guestfs_config.cmi guestfs_config.ml
std_utils.cmx : guestfs_config.cmi guestfs_config.cmx [...]
std_utils.cmx still depends on both files, but there is an extra rule
which ensures that guestfs_config.cmx isn't built in parallel with
guestfs_config.cmi.
I tested this change by running this command:
$ while ( rm common/mlstdutils/.depend; make -C common/mlstdutils/ clean && make -C common/mlstdutils/ ) >& /tmp/log; do echo -n .; done
Before the change it would fail after about 100 iterations. After the
change it ran for 10000s iterations and did not fail ever.
Updates commit 6d0ad49d5e.
In the case where we have a module.ml without a corresponding
module.mli file, ocamldep generates (correct) dependencies:
module.cmx module.cmi : module.ml
but we had no rule telling make how to generate the module.cmi
file from module.ml.
This didn't matter very much because when make came to build
module.cmx, the module.cmi file is generated as a side-effect.
However for highly parallel builds, the build ordering was still
incorrect. Any other module that depends on module.cmi could be built
in parallel. You would very occasionally see errors like this one:
File "_none_", line 1:
Error: Files index.cmx and utils.cmx
make inconsistent assumptions over interface Utils
Fixing this involves adding a ‘%.cmi: %.ml’ rule. However we have to
be careful that make doesn't run this rule instead of the ‘%.cmi: %.mli’
rule (if module.mli did exist). It turns out that GNU make says we
can depend on rule ordering in the Makefile for this.
I found that this only works correctly if we use "%"-style pattern
rules (not the ‘.ml.cmi:’ old-style rules).
This is *still* not a complete fix. Make still doesn't know that the
rules ‘%.cmo: %.ml’ and ‘%.cmx: %.ml’ also build the .cmi file as a
side-effect, so you can still occasionally see build failures.
However I could not work out how to add the extra information to the
dependencies without causing make itself to go into an infinite loop.
It may be that in the end we will have to get rid of pattern rules
completely and generate the complete OCaml rule set.
Apply this change across all the shell scripts containing tests.
Additionally this defines the environment variables $abs_srcdir,
$abs_builddir, $top_srcdir, $top_builddir, $abs_top_srcdir and
$abs_top_builddir which can now be used throughout test scripts.
This macro(?) expands to some shell script to source the
tests/test-functions.sh file from its correct location. The intention
is to use this in all tests, but in this commit only the existing
tests which already include test-functions.sh are modified.
Run the following command over the source:
perl -pi.bak -e 's/(20[01][0-9])-2016/$1-2017/g' `git ls-files`
(Thanks Rich for the perl snippet, as used in past years.)
Add makefile variables to enable silent rules for simple command
invocations, such as ocamlc, ocamlopt, javac, and erlc.
This reduces the log output when building with silent rules, still
showing the full command lines otherwise.
This file is mainly a central place to:
- include localenv if it exists, and
- define the RHEL 5 backwards compatibility macros, instead of
spreading them over every other file.
Previously, every subdirectory that contained generated files would
cause a recursion into the ../generator directory. This was slow and
unnecessary. Only recurse if the generator actually needs to be
rerun.
Note this changes the semantics slightly: For example if you added a
new action and just ran `make -C ocaml' then previously the generator
would be rerun, but now it would not. However I'm not convinced the
previous semantics were that useful, particularly considering that
with this change a simple `make' is much faster.
Because the generator subdirectory is cleaned first, and other
directories recurse into the generator directory, 'make distclean'
would fail (because generator/Makefile would be deleted by that
point).
Change subdirs-rules.mk so it doesn't fail if generator/Makefile has
been deleted already.
'src/generator.ml' is no more. Instead the generator is logically
split up over many different source files.
Read generator/README for help and tips.
We compile the generator down to bytecode, not native code. This
means it will run more slowly, but is done for maximum portability.
make all in the perl directory was missing a check that the library had been
built.
make check in the perl directory was missing a check that the appliance and test
images had been built.
This change adds an explicit dependency on generator.ml for every file it
generates, except java files. Java is left for another time because it's
considerably trickier.
It also adds a build rule for src/libguestfs.la so it can be rebuilt as required
from other directories.
It does this by creating a top level make file, subdir-rules.mk, which can be
included from sub-directories. sub-directories need to define 'generator_built'
to include local files which are built by generator.ml, and they will be updated
automatically.
This fixes parallel make, and will automatically re-create generated files when
make is run from any directory.
It also fixes the problem which efad4f53 was targetting. Specifically,
src/guestfs_protocol.(c|h) had an erroneous dependency on stamp-generator, and
therefore generator.ml, despite not being directly created by it. This caused
them to be recreated every time generator.ml ran rather than only when
src/guestfs_protocol.x was updated, which cascaded into a daemon and therefore
appliance update.
This patch also changes the contents of the distribution tarball by including
files created by rpcgen.
