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
htsutil_subcmd.diff
Description: htsutil_subcmd.diff
