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

The code is at 
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


Reply via email to