Re: [PATCH 2/3] gnu: Add python-pyxb.

[Marius Bakke]

Ben Woodcroft <address@hidden> writes:

> On 24/09/16 13:15, Marius Bakke wrote:
>> Ben Woodcroft <address@hidden> 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