[Pkg-cmake-team] Bug#948924: Bug#948924: Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
Felix Geyer
fgeyer at debian.org
Thu Jan 16 08:38:50 GMT 2020
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
More information about the Pkg-cmake-team
mailing list