TOOL_DEPENDS vs BUILD_DEPENDS

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

TL;DR: I propose to mass-change all uses of BUILD_DEPENDS outside
pkgsrc/mk to TOOL_DEPENDS, with no impact on native compilation and
possible benefits to cross-compilation.

Thoughts?


DETAILS

A decade ago I introduced TOOL_DEPENDS with the following semantics:

1. Package A TOOL_DEPENDS on package B if building package A requires
   executing programs installed by package B, like a compiler
   toolchain.  If A is cross-compiled, B must be a native package.

2. Package A BUILD_DEPENDS on package B if building package A requires
   data files installed by package B as inputs, like header files or
   libraries, such as libl for libflex.  If A is cross-compiled, B
   must also be cross-compiled.

For native compilation, these two coincide, of course.  So it is easy
to make a mistake about which one to use.

In retrospect, this may have been a mistake: essentially the only
legitimate uses of BUILD_DEPENDS come out of buildlink3.mk, so I
probably should have just renamed that to BUILDLINK_DEPENDS and used
it internally in buildlink3.mk, but it seemed riskier to cosmetically
touch infrastructure I wasn't otherwise changing.

Now we have about a thousand uses of TOOL_DEPENDS and three thousand
uses of BUILD_DEPENDS, the vast majority of which should be
TOOL_DEPENDS -- indeed, I don't know of a single case of BUILD_DEPENDS
outside buildlink3 that _shouldn't_ be TOOL_DEPENDS.

So, I propose to mass-change BUILD_DEPENDS to TOOL_DEPENDS outside
pkgsrc/mk.


Risks:
- Might catch something that really should be BUILD_DEPENDS, and
  thereby break cross compilation of that package.
- No risk to native compilation because the semantics is the same.

Benefits:
- Larger set of packages may become cross-compilable out of the box.