[Bug 223273] [NEW PORT] biology/sra-tools: NCBI's toolkit for handling data in INSDC Sequence Read Archives

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223273

            Bug ID: 223273
           Summary: [NEW PORT] biology/sra-tools: NCBI's toolkit for
                    handling data in INSDC Sequence Read Archives
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: mzaki at niid.go.jp

SRA tools is a toolkit for using data in the INSDC Sequence Read Archives.

SRAs operated by International Nucleotide Sequence Database Collaboration
houses sequence reads and alignments generated by "next-gen" sequencers.
SRA tools allows conversion of SRA files, which INSDC SRAs maintain,
from/to other formats that the sequenecers generate including fastq, sff, etc.

The source codes are available in 3 components, ngs, ncbi-vdb, and sra-tools,
to which the ports basically correspond.

biology/ngs-sdk:   C++ front-end API and others (a part of GitHub repo
ncbi/ngs)
biology/ncbi-vdb:  virtualized back-end engine library (GitHub repo
ncbi/ncbi-vdb)
biology/sra-tools: executables (GitHub repo ncbi/sra-tools)

However, separation and dependencies among them are somewhat strange:
* ncbi-vdb depends on the source code of ngs-sdk
* sra-tools depends on the build results of ncbi-vdb as well as ngs-sdk library

Java- and Python-related libraries are excluded from the ports,
since they are not necessary for building sra-tools executables
and thus out of popular demand, I believe; somebody can make separate ports.

Other changes
* to modify the build system to adapt FreeBSD
* to respect CC, CXX, CFLAGS, LDFLAGS, etc.
* to use system or locally installed libraries rather than bundled one

Note:
Building of sra-tools is successful on i386; however, resultant binary produces
somewhat strange outputs.
The upstream says "[...] we can look at providing support for an x32 build,
although since we can't guarantee that it works."
https://github.com/ncbi/ncbi-vdb/issues/8
So I dare to mark BROKEN_i386. On the other hand, amd64 binary seems OK.

-- 
You are receiving this mail because:
You are the assignee for the bug.