search

smithlabcode / preseq

Software for predicting library complexity and genome coverage in high-throughput sequencing.
https://preseq.readthedocs.io
GNU General Public License v3.0
78 stars 16 forks source link

Allow linking against system samtools #14

Closed rekado closed 8 years ago

rekado commented 9 years ago

I'm packaging preseq for Guix and would like to link against a binary version of samtools that is already available on the system rather than linking in samtools objects from a source checkout. Is this possible?

More specifically, samtools 1.1 and later comes with libbam.a. Would linking against this library be sufficient?

timydaley commented 9 years ago

Are you talking about linking to the samtools binary? That won't work. We don't use the samtools binary, but instead use the samtools API (which are the samtools objects). So the answer would be no. If I misunderstood your question, I apologize and ask that you please explain in a more detail. Thanks.

On Tue, Jun 23, 2015 at 1:23 AM, rekado notifications@github.com wrote:

I'm packaging preseq for Guix and would like to link against a binary version of samtools that is already available on the system rather than linking in samtools objects from a source checkout. Is this possible?

— Reply to this email directly or view it on GitHub https://github.com/smithlabcode/preseq/issues/14.

Timothy Daley University of Southern California

rekado commented 9 years ago

Samtools 1.1 and later comes with libbam.a. This is the library I'm hoping preseq could be linked against to avoid unnecessary bundling with third-party sources (such as Samtools). The Ruby bindings for Samtools, for example, are just wrapping libbam and do not need to be linked with the objects.

rekado commented 9 years ago

I just realised that Samtools 0.1.16 is used, not Samtools 1.x.

I successfully replaced the compiling of and linking against individual objects of the bundled samtools sources with linkage against libbam.a from Samtools 0.1.19. I did so by replacing $(addprefix $(SAMTOOLS_DIR)/, sam.o bam.o ...) with $(LIBBAM), passing the location of libbam.a as a make variable.

I also had to add the link flag -pthread without which libbam cannot be linked.

If I made this optional, dependent on the existence of a LIBBAM variable, would you be willing to accept a patch to the Makefile?

rekado commented 9 years ago

To note: some of the bundled header files (e.g. "sam.h") are still required, but at least it is no longer necessary to actually build the bundled copy of Samtools.

timydaley commented 9 years ago

Awesome! Yeah, we haven't updated to the most recent version of the samtools API because there was a significant reorganization when they moved from 0.1* to 1.0* and several functions that we use were taken out. We have discussed updating it (it's not just preseq, but a lot of the smithlab tools that would need to change) and have held off. I will bring this up again with the other members. Thanks!

On Thu, Jun 25, 2015 at 5:46 AM, rekado notifications@github.com wrote:

To note: some of the bundled header files (e.g. "sam.h") are still required, but at least it is no longer necessary to actually build the bundled copy of Samtools.

— Reply to this email directly or view it on GitHub https://github.com/smithlabcode/preseq/issues/14#issuecomment-115239891.

Timothy Daley University of Southern California