[Pkg-cmake-team] Bug#948924: Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34

[Felix Geyer]

On 14.01.20 23:33, Mattia Rizzolo wrote:
> Hi Felix,
> 
> thank you for the quick follow up
> 
> On Tue, Jan 14, 2020 at 10:29:26PM +0100, Felix Geyer wrote:
>>> your package failed to rebuild in a sid/amd64 chroot against libslt 1.1.34.
>>
>> The problem seems to be that cmake's FindLibXslt can't deal with the headers
>> being split across /usr/include and /usr/include/<arch>.
> 
> Why do you say so?
> That part hasn't change for many many years (since 2017! version
> 1.1.29-3), and in particular doesn't change between the version
> currently in unstable and experimental:

You are right of course. I jumped to my conclusion a bit too early.

> I forgot to mention indeed that besides dropping the xslt-config I also
> dropped the static library, I hope that cmakes doesn't depend on it :)
> 
>> Would you consider moving all headers to /usr/include/<arch>? This should make
>> libxslt's packaging easier and avoid special cases in build systems like cmake
>> that try to detect it.
> 
> The fact that the single file xsltconfig.h is within the arch-specific
> path indeed comes from the packaging and I could move it all; that said,
> I can't imagine why cmake would even notice such thing.  Tring to
> '#include <libxslt/xsltconfig.h>' ought to work regardless; if you are
> depending and checking the specific location of header files that are
> places in standard location, I deem to say that you are not doing
> yourself any favour. :)
> 
> Could you perhaps point me toward the pieace of code in cmake that is
> dealing with this, and what is failing?  Perhaps I'm able to help out a
> bit.

The code is at https://salsa.debian.org/cmake-team/cmake/blob/master/Modules/FindLibXslt.cmake
If pkg-config is installed it takes the version from there and everything
should work fine.
Otherwise it uses the path of libxslt/xslt.h and parses the version from
xsltconfig.h in the same path. This fails as xsltconfig.h is in a different
path. But as you pointed out this already fails with the package from unstable.

The problem is actually triggered by having libxslt1-dev installed in your
build chroot. In a clean cmake package build libxslt1-dev is not installed
and cmake just skips the tests that fails in your build.

So we can
a) ignore it (until the cmake build somehow pulls in libxslt)
b) make cmake build-depend on pkg-config
c) move all xslt headers into the same path

Cheers,
Felix