share/mk: Deduplicate some handling of debug info

[markj]

Summary

bsd.prog.mk and bsd.lib.mk contain a bunch of duplicated logic used to
handle DEBUG_FLAGS and standalone debug file info (enabled by
MK_DEBUG_FILES). In anticipation of adding more duplicated logic, let's
try factoring it out into a separate bsd.debug.mk first.

bsd.debug.mk now handles the following:

• MK_ASSERT_DEBUG
• installation rules for debug files (the consumer has to set DEBUGFILE)
• updating CFLAGS and CXXFLAGS based on DEBUG_FLAGS
• optionally stripping installed files

No functional change intended.

[bdrewery]

Seems okay. Be sure to test a bsd.progs.mk user too.

[markj]

I tested this by doing a reproducible buildworld+installworld, with and without the patch. I ran diff -r to look for differences in the installed directories. The only ones are in /rescue binaries. This is due to a small behaviour changes here which I think is harmless: before, bsd.prog.mk would not add DEBUG_FLAGS to CFLAGS if CRUNCH_CFLAGS was set. (But bsd.lib.mk added it regardless.) So now bsd.prog.mk behaves like bsd.lib.mk, i.e., we don't do anything special for crunchgen binaries. That is, rescue files are built with -g and stripped, resulting in slightly different executables.

[markj]

• Add a top-level comment
• Remove a guard whose purpose I'm not sure about
• Remove an unneeded include

[bdrewery]

It's fine to remove the guard but it's not a bad idea to have it there too.

Can you also add this file to bsd.README?

I don't recall what, if any, pattern we have for not-user-includable files. But worth mentioning something there still.

[markj]

In D51805#1184000, @bdrewery wrote:

It's fine to remove the guard but it's not a bad idea to have it there too.

What exactly do the guards protect against?

Can you also add this file to bsd.README?

Will do.

I don't recall what, if any, pattern we have for not-user-includable files. But worth mentioning something there still.

I extended the comment a bit.

[markj]

• List the file in bsd.README
• Note in the header comment that user makefiles shouldn't include this directly

[markj]

I'll commit this in a few days if there are no objections.

[emaste]

Looks OK, no objection.