guestmount.1 depends on translated files blocksize-option.pod,
key-option.pod & keys-from-stdin-option.pod (via __INCLUDE__
directives). If these are not yet translated by the time we try to
generate guestmount.1 then it will fail with:
podwrapper.pl: key-option.pod: cannot find input file on path at /builddir/build/BUILD/libguestfs-1.50.1/podwrapper.pl line 672.
This happens especially in parallel builds. Fix this by writing the
guestmount.1 rule explicitly, with the correct dependencies.
(cherry picked from commit 87b4d19f85)
(cherry picked from commit 17061cf496)
I noticed that 1-byte translated POD files were being generated in the
output directory (po-docs/ja/). This seems to have happened because
po4a-translate was generating an error, but because we were
immediately pipeing the output into sed the error was suppressed.
By running them as two separate commands this cannot happen.
Fixes: commit bd896d68c0
(cherry picked from commit d755070346)
(cherry picked from commit bebec890e2)
This was missed from earlier commit 25ddaefb03 ("docs: Recreate
guestfs-release-notes(1) page").
Fixes: commit 25ddaefb03
(cherry picked from commit d829778529)
(cherry picked from commit 4a04ab9255)
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').
Use a LINGUAS file with the list of available translations instead of
defining them in a make variable. This way Weblate will be able to
update the list using an available addon, and we do not need to list
those not built.
Accordingly, rename the variable with built languages to
'linguas_translated'.
Start the message extraction from the toplevel source directory, so the
file references are relative to that, instead of relative to this
po-docs subdirectory.
Also update/regenerate podfiles accordingly.
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>
The guestfish man page uses also additional POD snippets, so list them
as dependencies to make sure they are up-to-date.
This does not change the behaviour at the moment, however it will matter
when each traslated POD file will be generated on its own.
After the proposed split of the libguestfs repo, we will end up with
the following layout:
libguestfs.git
common -> git submodule libguestfs-common.git
generator
virt-v2v.git
common -> git submodule libguestfs-common.git
guestfs-tools.git
common -> git submodule libguestfs-common.git
The generator will only be able to write to libguestfs directories and
the common directory/submodule. This is mostly the case already with
only 6 exceptions:
customize/customize-options.pod
customize/customize-synopsis.pod
customize/customize_cmdline.ml
customize/customize_cmdline.mli
v2v/uefi.ml
v2v/uefi.mli
This commit moves these files around so they appear under common/ml*
It is somewhat unsatisfactory because it involves copying files
around, but there are some mitigating factors:
(1) Any changes now give us more freedom to develop faster and thus
clean things up in future.
(2) The v2v/uefi files ought to go away in future anyway.
This is simple code motion and should have no effect on the built
programs or tests.
