Andreas Tille wrote:
> I do not fully understand why the htsutil binary should not stay in the
> bedtools package
If I were a Debian user who had installed the bedtools package, I would be confused by that package creating a /usr/lib/bedtools directory -- because bedtools does not have plugins or similar that would warrant such a /usr/lib subdirectory. I would be surprised to find an undocumented executable named "htsutil" in there, and would be annoyed if I found out that it was purely for test purposes and of no use to me (as I don't have the test data or scripts) but had been non-optionally installed on my machine nonetheless by the supposedly user-oriented main bedtools package.
> Alternatively I see the option to simply ship the code for htsutil
> inside bedtools-test package and rebuild it before running the test.
> What do you think?
I think you would find that you needed to include a lot of source files, not just htsutil.cpp, to be able to rebuild it. So it's not a great path to go down, and more work than having two bedtools-test / bedtools-testdata subpackages would be.
This is the approach used in Debian's htslib-test package, which rebuilds the htslib test harnesses from source. This is bad for two reasons: (1) htslib-test needs to include practically all the source code and build infrastructure; (2) it's testing the copy of the htslib routines produced by this recompilation -- it is not testing libhts.so as installed by the libhts3 package. For htslib-test the latter is IMHO a bug, for which I will send a patch if it ever gets to the top of my to-do list.
There is however another truly simpler alternative.
There is precedent (the undocumented regresstest subcommand) for having testing facilities in the main bedtools executable; if I had thought a separate htsutil executable would give Debian heartburn I might have put it within the bedtools executable too. I'm not going to propose that upstream at this point, but you could apply a patch like the attached to not build an htsutil executable at all. So neither package would need to include htsutil; instead that code would add a mere 6K to the size of the bedtools executable. Then (after the upcoming upstream release) your run-unit-test script would be able to run it by setting htsutil='/usr/bin/bedtools htsutil' when it runs test.sh.
John
Attachment:
htsutil_subcmd.diff
Description: htsutil_subcmd.diff