Hash :
bbe5827c
Author :
Date :
2025-04-28T17:21:05
doc: Build docs with Doxygen and xsltproc Build the documentation as part of the build process with support for all build systems. This adds a new configuration option --with-docs to build documentation. Required tools are Doxygen, xsltproc and the DocBook 4 XSLT stylesheets. Doxygen will also be required to build the Python bindings.
Most of the tests are contained in the runtest executable which
generally reads test cases from the test directory and compares output
to files in the result directory.
You can simply add new test cases and run runtest -u to update the
results. If you debug test failures, it’s also useful to execute
runtest -u and then git diff result to get a diff between actual and
expected results. You can restore the original results by running
git restore result and git clean -xd result.
Some source code is generated with Python scripts in the tools
directory.
tools/genChRanges.py generates code to handle character ranges
from chvalid.def:
chvalid.c include/libxml/chvalid.h
tools/genEscape prints lookup tables for serialization. -tools/genHtml5LibTests.pycreates test cases and expected results from the html5lib test suite: -test/html-tokenizer-result/html-tokenizer-tools/genHtmlEnt.pyprints lookup tables for HTML5 named character references (predefined entities): -html5ent.inc-tools/gentest.pygenerates test code using the Doxygen XML output: -testapi.c-tools/genUnicode.pygenerates code to handle Unicode ranges from Unicode data files: -xmlunicode.c## Making a release ### Update the NEWS file You can get started by running git log --format='- %s (%an)' [previous-release-tag].. ### Bump the version number Update the version number inVERSIONif you haven't done so already. ### Commit and verify tarball Release tarballs are generated with a CI job and the.gitlab-ci/dist.shscript. Push the release commit and inspect the tarball artifact generated by Gitlab CI. ### Tag the release Create an annotated tag and push it: git tag -a [version] -m 'Release [version]' git push origin [version] This will upload the release to the downloads server using the GNOME Release Service. For more details, see <https://handbook.gnome.org/maintainers/release-pipeline.html> ### Create a GitLab release Create or update a GitLab release on <https://gitlab.gnome.org/GNOME/libxml2/-/releases>. ### Announce the release Announce the release on https://discourse.gnome.org under topics 'libxml2' and 'announcements'. ## Breaking the ABI Unfortunately, libxml2 exposes many internal structs which makes some beneficial changes impossible without breaking the ABI. The following changes are allowed (after careful consideration): - Appending members to structs which client code should never allocate directly. A notable example is xmlParserCtxt. Other structs like xmlError are allocated directly by client code and must not be changed. - Making a void function return a value. - Making functions accept const pointers unless it's a typedef for a callback. - Changing signedness of struct members or function arguments. ## Updating the CI Docker image Note that the CI image is used for libxslt as well. First create a GitLab access token with maintainer role andread_registryandwrite_registry` permissions. Then run the following commands with the
Dockerfile in the .gitlab-ci directory:
docker login -u <username> -p <access_token>
registry.gitlab.gnome.org
docker build -t registry.gitlab.gnome.org/gnome/libxml2 -
< .gitlab-ci/Dockerfile
docker push registry.gitlab.gnome.org/gnome/libxml2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112
# Maintainer's Guide
## Working with the test suite
Most of the tests are contained in the `runtest` executable which
generally reads test cases from the `test` directory and compares output
to files in the `result` directory.
You can simply add new test cases and run `runtest -u` to update the
results. If you debug test failures, it's also useful to execute
`runtest -u` and then `git diff result` to get a diff between actual and
expected results. You can restore the original results by running
`git restore result` and `git clean -xd result`.
## Generated files
Some source code is generated with Python scripts in the `tools`
directory.
- `tools/genChRanges.py` generates code to handle character ranges
from chvalid.def:
- `chvalid.c`
- `include/libxml/chvalid.h`
- `tools/genEscape prints lookup tables for serialization.
- `tools/genHtml5LibTests.py` creates test cases and expected results
from the html5lib test suite:
- `test/html-tokenizer`
- `result/html-tokenizer`
- `tools/genHtmlEnt.py` prints lookup tables for HTML5 named character
references (predefined entities):
- `html5ent.inc`
- `tools/gentest.py` generates test code using the Doxygen XML output:
- `testapi.c`
- `tools/genUnicode.py` generates code to handle Unicode ranges
from Unicode data files:
- `xmlunicode.c`
## Making a release
### Update the NEWS file
You can get started by running
git log --format='- %s (%an)' [previous-release-tag]..
### Bump the version number
Update the version number in `VERSION` if you haven't done so already.
### Commit and verify tarball
Release tarballs are generated with a CI job and the `.gitlab-ci/dist.sh`
script. Push the release commit and inspect the tarball artifact generated
by Gitlab CI.
### Tag the release
Create an annotated tag and push it:
git tag -a [version] -m 'Release [version]'
git push origin [version]
This will upload the release to the downloads server using the GNOME
Release Service. For more details, see
<https://handbook.gnome.org/maintainers/release-pipeline.html>
### Create a GitLab release
Create or update a GitLab release on
<https://gitlab.gnome.org/GNOME/libxml2/-/releases>.
### Announce the release
Announce the release on https://discourse.gnome.org under topics 'libxml2'
and 'announcements'.
## Breaking the ABI
Unfortunately, libxml2 exposes many internal structs which makes some
beneficial changes impossible without breaking the ABI.
The following changes are allowed (after careful consideration):
- Appending members to structs which client code should never allocate
directly. A notable example is xmlParserCtxt. Other structs like
xmlError are allocated directly by client code and must not be changed.
- Making a void function return a value.
- Making functions accept const pointers unless it's a typedef for a
callback.
- Changing signedness of struct members or function arguments.
## Updating the CI Docker image
Note that the CI image is used for libxslt as well. First create a
GitLab access token with maintainer role and `read_registry` and
`write_registry` permissions. Then run the following commands with the
Dockerfile in the .gitlab-ci directory:
docker login -u <username> -p <access_token> \
registry.gitlab.gnome.org
docker build -t registry.gitlab.gnome.org/gnome/libxml2 - \
< .gitlab-ci/Dockerfile
docker push registry.gitlab.gnome.org/gnome/libxml2