IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The global struct is quite large (~700 bytes on 64-bit systems which
will be allocated for each thread whether it uses libxml2 or not) and
already close to the total size limit on some platforms.
Disable compiler TLS by default.
Trio is a rather old cross-platform printf library which was bundled with
libxml2. It was needed for ancient pre-C99 systems without snprintf and
should be safe to remove these days.
Using `pkg_check_modules(FOO IMPORTED_TARGET foo)` with
`target_link_libraries()` leads to `INTERFACE_LINK_LIBRARIES` in the
resulting export file having `\$<LINK_ONLY:PkgConfig::FOO>` rather than
the currently expected `\$<LINK_ONLY:FOO::FOO>`, leading to breakage.
This can be worked around like so:
target_link_libraries(UseFoo
PUBLIC "$<BUILD_INTERFACE:PkgConfig::FOO>"
INTERFACE "$<INSTALL_INTERFACE:FOO::FOO>"
)
However, following some discussion, it is preferable to primarily use
find modules as before and only use `pkg_check_modules` for correctly
populating the .pc file.
Also move `find_package()` calls earlier so that builds fail faster when
dependencies are missing.
-Wnested-externs produces spurious warnings after implicit
declaration of functions.
-Winline is useless since we don't use inlines.
-Wredundant-decls was already removed for autotools.
I recently fixed this for Autotools but said that fixing this for CMake
was not feasible due to it using `find_package` rather than
`pkg_check_modules`. I then thought about it and couldn't find any
reason why CMake couldn't try `pkg_check_modules` first and then fall
back to `find_package`, as that's basically what Autotools does.
I had wanted to use the linker flags generated by CMake when it does
fall back to `find_package`, but it only returns direct paths to the
libraries, as opposed to `-l` flags. Baking these library paths into the
pkg-config and xml2-config files would break static linking and
cross-compiling, so I've stuck with the `-l` flags we already have.
There is no need to set `CMAKE_REQUIRED_LIBRARIES` because we already
add the dependencies to the library target.
pkg-config supports `Requires.private` and `Libs.private` fields for
static linking. However, if you're building a dynamic binary, then
pkg-config will use the non-private fields, even if just the static
libxml2 is available. This will result in libxml2 being underlinked,
causing the build to fail. The solution is to fold the private fields
into the non-private fields when the shared libxml2 is not being built.
This works for Autotools and CMake. Meson also knows how to handle this
when it automatically generates pkg-config files.
The -I and -L flags you use to build should not necessarily be the same
ones you bake into installed files. If you are building with
dependencies located under a SYSROOT then the installed files should
have no knowledge of that SYSROOT. For example, if the build requires
`-L/path/to/sysroot/usr/lib/foo` then only `-L/usr/lib/foo` should be
baked into the installed files.
pkg-config is SYSROOT-aware, so this issue can be sidestepped by using
the `Requires` field rather than the `Libs` and `Cflags` fields. This is
easily resolved if you rely solely on pkg-config, but this project falls
back to standard Autoconf checks, so a little more effort is required.
Unfortunately, this issue cannot feasibly be resolved for CMake.
`find_package` is used rather than `pkg_check_modules`, so we cannot
tell whether a pkg-config file for each dependency is present or not,
even if `find_package` uses pkg-config behind the scenes. The CMake
build does not record any dependency -I or -L flags into the pkg-config
file anyway. This is a problem in itself, although these dependencies
are most likely installed to standard locations.
Meson is very much better at handling this, as it generates the
pkg-config file automatically using the correct logic.
This enables some tests with testcases in
- test/xsdtest
- test/relaxng/OASIS/spectest.xml
- test/relaxng/testsuite.xml
The XML Schema Test Suite will also be run it was downloaded, see
xstc/Makefile.am. Gitlab CI should be updated to fetch these files.
There are 10 expected errors in the XSD test suite. This seems to be the
case since at least version 2.9.0 from 2012.
Add a new configuration flag that controls whether the outdated support
for XPointer locations (ranges and points) is enabled.
--with-xptr-locs # Autotools
LIBXML2_WITH_XPTR_LOCS # CMake
The latest spec for what it essentially an XPath extension seems to be
this working draft from 2002:
https://www.w3.org/TR/xptr-xpointer/
The xpointer() scheme is listed as "being reviewed" in the XPointer
registry since at least 2006. libxml2 seems to be the only modern
software that tries to implement this spec, but the code has many bugs
and quality issues.
The flag defaults to "off" and support for this extensions has to be
requested explicitly. The relevant API functions are deprecated.
Remove all the parts of the old test suite which are covered by
runtest.c for quite some time.
The following test programs are removed:
- testC14N
- testHTML
- testReader
- testRelax
- testSAX
- testSchemas
- testURI
- testXPath
This also removes a few results of unimportant tests only run by the old
test suite.
