On 2020-01-15 03:21, Mattia Rizzolo wrote:
Oh wow.
So it turns out that my attempt at hastening the rebuilds by
pre-installed the new binaries in the choort backfired here.
Having said that, reading that .cmake file is't not clear to me why it
would skip the test if libxslt1-dev is not installed.
That part is in the test code:
https://salsa.debian.org/cmake-team/cmake/blob/master/Tests/CMakeOnly/AllFindModules/CMakeLists.txt#L58
So we can
a) ignore it (until the cmake build somehow pulls in libxslt)
I'd probably go for this and close this bug if you agree.
Yes, I might even disable this particular unit test during the build
since the
autopkgtest is much better suited for it.
b) make cmake build-depend on pkg-config
Your call.
c) move all xslt headers into the same path
I'd rather avoid changing upstream's configuration even more.
Imho moving xsltconfig.h to a different directory deviates much more
from upstream than passing the multiarch path in --includedir.
For example the pkg-config file is technically not correct as it just
sets:
includedir=${prefix}/include
Cflags: -I${includedir}
Of course it mostly just works anyway because everything is in the
default compiler
search path but still ...
There is also a d) have that .cmake file use find_path() also to detect
the path of libxslt/xsltconfig.h, instead of assuming it lives with
xslt.h.
I guess, but you need to make sure that xsltconfig.h really is from the
same version
in case there are multiple libxslts installed.
Cheers,
Felix
