Bayesian haplotype-based polymorphism discovery and genotyping

[jwb]

Summary

Bayesian haplotype-based polymorphism discovery and genotyping
Approved by jrm (mentor) or wen (mentor)
Differential to be added to commit message

Upstream is a mess here, but there isn't a lot we can do about it now.

E.g. there are two different versions of htslib and intervaltree pulled in as
submodules, all of which are older versions than the ports. I made sure
the freebayes build uses only static libs for all submodules to prevent
runtime mishaps.

I attempted to work with the developers a while back but most of my
inquiries/suggestions were ignored. I think they're just not interested
in supporting anything beyond git clone --recursive && make.

I also think I've discovered a limitation of GH_TUPLE. See comments in
Makefile.

If you think there's any way to make this cleaner, please suggest...

Test Plan

portlint -AC: looks fine
Passed poudriere on {10.3,11.1}-{amd64,i386}
Tested in production

[jrm]

biology/freebayes/Makefile

6 ↗

(On Diff #41574)

-wip

[jwb]

Yeah, I didn't bother testing this one as I'm hoping for some discussion
before I commit. Should have done so anyway. I'm going to script the
import process to remove the wip category, run port-check, and open
category/Makefile so I won't miss anything in the future.

[jrm]

This certainly is a mess with the circular redundant submodule dependencies. Is SeqLib-temp necessary? For some reason, vcflib-5e3ce04/ is being put under ${WRKSRC}/vcflib instead of its contents. We could wait to see if @mat comments, but I feel like your hack is a reasonable workaround. Let me know if you would prefer to wait, or if you would like me to approve.

[jwb]

Yeah, I get the same problem with SeqLib and vcflib, as both of them have submodules. If I list them directly in GH_TUPLE, they get blanked when their submodules are moved into place. I didn't notice it at first with SeqLib, because there are no patches in that directory. patch-vcflib_Makefile failed when I added ekg:fastahack:c68cebb:fastahack/vcflib/fastahack, which is what tipped me off to the problem.

I can wait a bit for some feedback on this. We're still testing ddocent anyway, so there's no rush to commit.

If there is an issue with GH_TUPLE, this might be a chance to test a fix. The docs on it are pretty sparse, so I had to go by trial and error and examining the Mk files.

[jwb]

What were you saying about the vcflib contents? Here's what I'm seeing:

root@unixdev1:/usr/ports/wip/freebayes # ls work/freebayes-1.2.0/vcflib/
1KG_Index/ README.md fsom/ multichoose/ smithwaterman/
LICENSE examples/ googletest/ paper/ src/
Makefile fastahack/ intervaltree/ samples/ tabixpp/
Makefile.orig filevercmp/ logos/ scripts/ test/

ddocent appears to be fully operational now, including the freebayes option, so I'm ready to commit this as is if you have no further suggestions.

Thanks...

[jrm]

With 'GH_TUPLE=walaj:SeqLib:5941c68:SeqLib/SeqLib \...' and ${MV} -n ${WRKSRC}/SeqLib-temp/* ${WRKSRC}/SeqLib removed from post-extract the build succeeds: http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2018-04-19_20h21m00s/logs/freebayes-1.2.0.log but I didn't not dig deeply.

My comment about vcflib wasn't clear. I was describing the layout of ${WRKSRC} without your workaround with the temp directory. Just think out loud and exploring a little...

[jwb]

Well that's interesting... A couple days ago SeqLib was behaving like vcflib, ending up empty except for the subdirectories. I only noticed it after the vcflib patch failed and I realized that these are the two submodules with submodules. I don't think I trust this new development, so I'll leave the hack in until we get to the bottom of this.