Hi @orlitzky,
welcome back, you always bring the most niche bugs with you :-)

Thank you for the PR.
I thought a bit about it and made #2063 where check_snmp just looses an option if snmpgetnext is missing.
But I do not have a strong opinion on which solution is preferable.
This one here is simpler and adds less Preprozessor Macros ...

Any opinions?

Ha, this one is so niche that I can't even explain it. Either PR is fine with me. I considered disabling the option myself but arrived at the current solution due to another (you're not gonna believe this) niche consideration.

On Gentoo, the automatic enabling of features based on the presence of certain dependencies can be a headache, because they sometimes get enabled incidentally. Our users build things from source and can usually enable/disable features explicitly, but the automatic detection can lead to plugins being enabled even when the user hasn't asked for it. For example, if the user happens to have net-snmp installed as a dependency of another program, and if he then builds monitoring-plugins, he will wind up with check_snmp installed even if he didn't enable the "snmp" flag for monitoring-plugins. So what happens is, he writes some SNMP service checks using check_snmp, because it's there, and then two years later, uninstalls the program that originally pulled in net-snmp. Now check_snmp starts segfaulting, and sends non-stop alerts to everyone's phones until he figures out that he wanted to enable the "snmp" flag for monitoring-plugins.

In that regard, --enable-snmp would be a better flag to have, because unless the user explicitly enabled it, he wouldn't get the plugin, so he couldn't build a configuration that accidentally depends on the plugin. Now, imagine a world where I actually have time to rework the ./configure detection for all of these plugins. In that world, I think it would make more sense for ./configure to just die if --enable-snmp was given but snmpgetnext was not found. If for no other reason, that would let us figure out WTF is happening on machines where snmpgetnext isn't found. But it could also avoid a similar situation where the user builds a configuration that depends on snmpgetnext and then later has the flag mysteriously disappear.

ok, wow, that's a headache.
Having explicit "positive" flags for all the plugins sounds like an idea worth considering. Although my motivation for touching that much autoconf stuff is low.
In any case, your PR avoids having more PP macros in the plugins and I am all for that and we will just ignore any setup where snmpgetnext is not available but snmpget is.

Although my motivation for touching that much autoconf stuff is low.

I actually don't mind it but there are always a hundred bigger fires to put out. Thank you!