[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