vasilito
a399e7da08
Survey of the working tree found 83 tracked files
that no longer exist on disk (tracked-but-missing).
Most were inside source/ dirs (extraction differences
between git revisions) and are out of scope for this
commit. The 28 non-source tracked-but-missing files
fell into these categories:
1. Broken self-referential symlinks in driver and
tui recipes (5 files):
- local/recipes/drivers/ehcid/ehcid ->
../../local/recipes/drivers/ehcid (loops)
- local/recipes/drivers/ohcid/ohcid -> ...
- local/recipes/drivers/uhcid/uhcid -> ...
- local/recipes/drivers/usb-core/usb-core -> ...
- local/recipes/tui/mc/mc -> ...
These were created by the now-removed
apply-patches.sh symlink-overlay system. Per
AGENTS.md § 'NO OVERLAY-STYLE PATCHES', the
overlay pattern is retired. Recipes now use the
`path = 'source'` form in [source] blocks
pointing at the in-tree Red Bear fork. The
self-referential symlinks broke because the
overlay indirection was removed.
2. Broken absolute-path symlinks in gpu/driver
recipes (2 files):
- local/recipes/gpu/drivers/linux-kpi/source
-> /mnt/data/homes/kellito/Builds/rbos/...
- local/recipes/gpu/drivers/redox-driver-sys/source
-> /mnt/data/homes/kellito/Builds/rbos/...
These were committed on a different filesystem
layout. The actual source trees are in
`local/sources/{linux-kpi,redox-driver-sys}/`
and are loaded via `path = 'source'` config.
3. Tracked empty `~` (emacs backup) files in
autotools-generated source dirs (13 files).
Autotools regen produces `configure~`,
`config.h.in~`, etc. whenever a developer runs
`autoreconf` in the source dir. These are
ephemeral working files, not upstream source.
Re-running the cookbook's autoreconf will
regenerate them on the next fetch.
4. Tracked-but-missing upstream WIP recipes
(12 recipes, 596 files):
- recipes/wip/dev/build-system/{meson,ninja-build}
- recipes/wip/dev/other/{bison,flex}
- recipes/wip/libs/gnome/libepoxy
- recipes/wip/libs/other/m4
- recipes/wip/libs/qt/qt6/{qt6-sensors,
qt6-sensors-local}
- recipes/wip/wayland/qt6-wayland-smoke
- recipes/wip/x11/{libxau,libxcb,x11proto}
These were tracked in the upstream Redox WIP
area but the underlying dirs/files no longer
exist on disk (likely removed when upstream
WIP was reorganized). They were never
referenced by any `config/redbear-*.toml`
and have no surviving tree dependencies.
5. Top-level `gparted-git/` orphan (4 files):
A staging dir from a previous attempt to add a
gparted recipe (RBPKGBUILD + import/). The recipe
was never finished and the postmortem H-4 says
it was 'removed' but the dir persisted.
6. `recipes/gpu/drivers` tracked as a file blob
but working tree has it as a directory.
Tree conflict from a prior overlay layout.
.gitignore additions:
- `*\~` (emacs backup)
- `.*.swp`, `.*.swo` (vim swap)
These patterns prevent future accidental commits
of ephemeral editor / autotools-regen files.
Net effect: 617 files removed, 1,304,942 lines
deleted from tracked history, 0 lines added. The
working tree is now 0 tracked-but-missing files
outside of source/ dirs (source/ extraction
differences are out of scope for this commit).
libxml2
libxml2 is an XML toolkit implemented in C, originally developed for the GNOME Project.
Official releases can be downloaded from https://download.gnome.org/sources/libxml2/
The git repository is hosted on GNOME's GitLab server: https://gitlab.gnome.org/GNOME/libxml2
Bugs should be reported at https://gitlab.gnome.org/GNOME/libxml2/-/issues
Documentation is available at https://gitlab.gnome.org/GNOME/libxml2/-/wikis
License
This code is released under the MIT License, see the Copyright file.
Build instructions
libxml2 can be built with GNU Autotools, CMake, or several other build systems in platform-specific subdirectories.
Autotools (for POSIX systems like Linux, BSD, macOS)
If you build from a Git tree, you have to install Autotools and start by generating the configuration files with:
./autogen.sh
If you build from a source tarball, extract the archive with:
tar xf libxml2-xxx.tar.gz
cd libxml2-xxx
To see a list of build options:
./configure --help
Also see the INSTALL file for additional instructions. Then you can configure and build the library:
./configure [possible options]
make
Note that by default, no optimization options are used. You have to enable them manually, for example with:
CFLAGS='-O2 -fno-semantic-interposition' ./configure
Now you can run the test suite with:
make check
Please report test failures to the mailing list or bug tracker.
Then you can install the library:
make install
At that point you may have to rerun ldconfig or a similar utility to update your list of installed shared libs.
CMake (mainly for Windows)
Another option for compiling libxml is using CMake:
cmake -E tar xf libxml2-xxx.tar.gz
cmake -S libxml2-xxx -B libxml2-xxx-build [possible options]
cmake --build libxml2-xxx-build
cmake --install libxml2-xxx-build
Common CMake options include:
-D BUILD_SHARED_LIBS=OFF # build static libraries
-D CMAKE_BUILD_TYPE=Release # specify build type
-D CMAKE_INSTALL_PREFIX=/usr/local # specify the install path
-D LIBXML2_WITH_ICONV=OFF # disable iconv
-D LIBXML2_WITH_LZMA=OFF # disable liblzma
-D LIBXML2_WITH_PYTHON=OFF # disable Python
-D LIBXML2_WITH_ZLIB=OFF # disable libz
You can also open the libxml source directory with its CMakeLists.txt directly in various IDEs such as CLion, QtCreator, or Visual Studio.
Dependencies
Libxml does not require any other libraries. A platform with somewhat recent POSIX support should be sufficient (please report any violation to this rule you may find).
However, if found at configuration time, libxml will detect and use the following libraries:
- libz, a highly portable and widely available compression library.
- liblzma, another compression library.
- libiconv, a character encoding conversion library. The iconv function is part of POSIX.1-2001, so libiconv isn't required on modern UNIX-like systems like Linux, BSD or macOS.
- ICU, a Unicode library. Mainly useful as an alternative to iconv on Windows. Unnecessary on most other systems.
Contributing
The current version of the code can be found in GNOME's GitLab at at https://gitlab.gnome.org/GNOME/libxml2. The best way to get involved is by creating issues and merge requests on GitLab. Alternatively, you can start discussions and send patches to the mailing list. If you want to work with patches, please format them with git-format-patch and use plain text attachments.
All code must conform to C89 and pass the GitLab CI tests. Add regression tests if possible.
Authors
- Daniel Veillard
- Bjorn Reese
- William Brack
- Igor Zlatkovic for the Windows port
- Aleksey Sanin
- Nick Wellnhofer