@mat can you please take a look at this? The recent b.s. on ports@ affirms for me the need to warn people against using systemically broken tools.

Had a dangling endif

I'm missing something. Are there multiple ports that provide doxygen binaries?

Ah sorry, forgot to reply here. Someone reported an error that seemed like it was caused by this, so I pushed the fix. Turns out he had some sort of environment contamination (building from ports), so it was a bad assumption on my part.

What is the status of this patch? What help can I be of here? I'll hold off on updating to 2.2.18 (just released) so as not to interfere here.

Sorry Alan, this was breaking the build on 11 so I committed it.

Normally I push hard against avoidable dependencies, but I think the right thing to do here is to make makeinfo non-optional. Major gnupg dependencies (like gnutls, libgcrypt, m4, nettle, and autoconf) depend on texinfo, so there's really nothing to gain from hiding it behind a MANPAGES option (which is normally used when dependencies are ludicrous, like pandoc or whatever nonsense python thing cmake uses).

This isn't the right approach. Manpages aren't docs like FAQ and HACKING and DETAILS; they're manpages and their existence shouldn't be controlled by the DOCS option.

I guess I should add to please make sure that make -C ${WRKSRC} check completes successfully.

I haven't tested this (I have no way of actually testing it), so I'm relying on you there. You definitely have my approval to commit this whenever you're ready.

After updating the DOCS_BUILD_DEPENDS (and also bumping PORTREVISION please), feel free to commit this anytime.

I'm fine with a date change in that context.

This seems tremendously fragile. Unless I'm misunderstanding, these massive patches would have to be regenerated for every update (assuming changes), which---while I appreciate the patch coming down the pipeline---I don't relish the thought of being responsible for.

In D22450#491430, @jhb wrote:

I think this probably warrants an exp-run before committing?

I applaud this move. It sets a great example of where individual maintainership should head: shared responsibility across the consumers who need to leverage it.

The committed version is a little weird. Sometimes the minimal dependency set is the ideal set, so saying it should never be it is misleading. Also, the last sentence isn't a sentence.

> Thanks. Some time ago @tobik wrote 6.5.8. Building Go Applications section that covers this process in details. It is tailored for Go modules, but I doubt that there will be much new Go software written that don't use them.

I'll approve it.

bsd.default-versions.mk is maintained by ports@. There’s no approval needed from our end on it.

Ah okay. I thought this was separate from OPTIONS.Then maybe:

Ok. So, my concern here is that (a) I don't know what an "extra dependency" looks like, and (b) sometimes the configuration that would benefit the most people is the minimal or maximal set.

This automatically flagged @portmgr because of go.mk. It's a formality, but you certainly have our approval for it.