Ben Woodcroft <b.woodcr...@uq.edu.au> writes: > On 24/09/16 13:15, Marius Bakke wrote: >> Ben Woodcroft <b.woodcr...@uq.edu.au> writes: >> >>>> Htslib is propagated because it >>>> is included by the installed samtools and bcftools headers; at least one >>>> of pysams dependencies failed to build when it was a regular input. >>> Ah, I see. Can this be avoided with patchelf? >> I don't think so. The htslib headers need to be propagated for anything >> that uses header files from pysam, since they contain contain code such >> as "include <htslib/foo.h>". Perhaps you can update the comment to make >> it more clear? >> >> Patchelf is probably what made that work when htslib was bundled. > Ah, ok I see, so the problem is that python-plastid requires the .h > files during build. Given that this is the only package that has an > issue, and perhaps pysam doesn't intend to provide these .h files as > part of it's "interface", I think it might be best to simply put htslib > as an input to python-plastid.
I'm not sure, we would have to do this with every package that uses the pysam cython interface. This particular issue is described in the manual: https://www.gnu.org/software/guix/manual/html_node/package-Reference.html The propagated-inputs section says "For example this is necessary when a C/C++ library needs headers of another library to compile, or when a pkg-config file refers to another one via its Requires field.". So I think it's a pretty common propagation scenario. See e.g. 618089f9 for a less convoluted case (C++ library that propagates zlib headers). Perhaps a "propagated-build-inputs" functionality would be useful, so that libraries are only propagated at build time and not to the profile. If we don't do propagation, at least add a comment to python-plastid explaining that htslib is there to avoid propagating from pysam, since the plastid code contains no direct references to htslib. Your other changes LGTM. Thanks! Marius
