> 	CONFIGURE_ENV+=	AWK=${AWK:Q}

The problem with numerous packages is that their Makefiles, scripts, whatever
do not necessarily honor AWK (or SED, or CP, etc.), so passing that
argument will not help there. Even the pkgsrc install-sh script does not honor
these variables. :-(
pkgsrc has a wonderful symlinking mechanism which it already employs for
tools specified by USE_GNU_TOOLS.
I am unsure whether the proposal discussed here alrady contains this,
but I think the most efficient approach would be to use that same logic
for symlinking the remaining ones as well, even "trivial" ones like cp
or mv.
(this would immediately render obsolete quite a bunch of PRs I have opened
for IRIX 5, and would solve even more issues for which I gave up opening a
PR).
I have tried to propose this a month ago (cf.
http://mail-index.NetBSD.org/tech-pkg/2005/03/02/0011.html), but noone seemed
to have picked up the thread.

If I understood correctly, the proposed code tries to scan the shell path
(with some pkgsrc-specific directories added) for the respective tools.
I see quite some trouble with this approach:

- it consumes quite resources when done for each package and for a number
of tools (would not be a decisive issue, but it is not really desirable)
- it assumes that the desired tool is in the path.
- I already with the current wrapper implementation have the issue that
it finds $LOCALBASE/bin/ld and uses that instead of the system /usr/bin/ld,
which I would like to. So far I did not anything I could do about this.
- as mentioned with the previous item I would very much prefer to have
the ability to precisely control which tool is actually being used for
$TOOL. If it is based on a directory scan I do not have that.

So I would rather prefer an approach similar to the use of USE_GNU_TOOLS
which would give the platform or, via mk.conf, even the user a more
precise control of what is being used.
Let me try to briefly explain this with the example of cp.
For an installation that can/wants to use its "standard" cp, i.e. the one
first in the path, there is nothing it needs to do anyway.
For other installations one would set SYMLINK_TOOLS+=cp (or whatever
the variable is called) either in the platform-specific config file or,
if the user chooses so, in mk.conf. Of course CP must also be set to point
to the appropriate tool.
Now all buildlink would have to do is, similar to USE_GNU_TOOLS, go though
SYMLINK_TOOLS and create the respective links .tools/bin/cp -> ${CP} (or
any other tool), unless that tool happens to be in USE_GNU_TOOLS, in which
case the latter would take prority of course.

I think this could be added nicely to the existing tools.mk framework and
should not need too much of extra code.

I admit these considerations do not yet take into account that some
tools might be desirable to be called with certain specific options.
I am just proposing doing so because I think it would be a simple but yet
very efficient approach to solving problems on platforms with certain inferior
standard tools.

In case I misinterpreted the proposed approach I would like to apologize and
ask for some corrective explanations :-)

-- 
Georg Schwarz    http://home.pages.de/~schwarz/
 georg.schwarz@freenet.de  +49 178 8545053