Yep, 'been using this for years, at least in my wip ports. Very handy for persnickety genomics ports.

No worries, I managed to find something else to do while I waited. ;-)

Good catch. I deliberately left it out because it's a compiled language,
but forgot that it's only installing headers.

Don't stop making suggestions until I stop making mistakes. ;-)

I think biology/Makefile should match the directory name, not PKGBASE.

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.

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

I don't know why it was added originally, but I've built the new version
at least a dozen times without it and run it through poudriere testport
twice on all platforms, so I'm pretty confident.

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.

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.

I'm not sure, actually. It's a dependency for vcflib and possibly other github/ekg tools. I'd rather not try to hack dependent ports to use a pkg command as I'd have to verify that it behaves exactly the same as this tool every time either one is updated.

I was actually following Example 5.13 on the DISTVERSION.

Human because he expected me to notice the missing lib/? ;-)

Interesting. I would not have thought to use anything outside WRKSRC in the
build.

localbase:ldflags is what I was looking for...

Agreed. Now that I'm aware of all the USE_GITHUB support for cases like this, I am definitely inclined to utilize it.

I see, I was only looking at the Naming section and didn't realize there was
more about this under USE_GITHUB. This is very nice...

Maybe you're looking at the p20170211 as a pre-release level? It's actually a post-release patch level. 0.1.p20170211 would be a pre-release, 0.1p20170211 is a patch level. Rather confusing, I think, but at least it's documented. We had a discussion about this a couple months ago and concluded that using PORTVERSION is the only way to specify a patch level.

I like it... Thanks.

wip: Just seeing if you were paying attention. ;-)

Yes, I was focused this time around. I've always been good during exams. ;-)

I think I copy/pasted that line late in the game, after checking for += lint. Note that I fixed LIB_DEPENDS and CMAKE_ARGS, but then missed this one. I fixed it in the WIP port so it will be corrected in the next commit. Thanks!

Are you referring to LDFLAGS+=? If so, I think that should be left as-is.

Regarding GNU_CONFIGURE: Yeah, I've always read this as "USES_GNU_CONFIGURE", so it seems logical to keep it in the USES section. Thanks...

Here's the best I can come up with short of setting up a web server and
testing, which I don't have time for. I'm not sure we have anyone here who
would know how to use it anyway. At least this points potential users in
the right direction.

I think that's worth exploring, but I'd rather wait until the next commit rather than potentially introduce a regression under time pressure.

Good idea. We don't use stacks directly here, only as a dependency for ddocent, which people run on our clusters. I'll take a look at how it might be used on a desktop machine and make some adjustments along the line you suggested.

Updated my checklist so this won't happen again.

Crap, sorry. I didn't scroll down to see your comment. I'm just overwhelmed with juggling too many things here...

I'll leave it alone for now rather than add noise to the commit log.

Do you consider this worth another commit, or should it wait until the next upgrade?

Yes, I did overlook your comment.