graphics/gphoto2 gratuitously adds -I and -L paths in ${LOCALBASE}. Since
these added paths are the only thing preventing gphoto2 from being strongly
buildlinked, I started wading through and patching them out.

I know gphoto2 is far from the only package that has had this problem, and
my train of thought led me along: what if setting USE_BUILDLINK_ONLY also
dropped a cc wrapper in ${BUILDLINK_DIR}/bin? The wrapper would remove bad
-I and -L paths before passing its arguments to the real ${CC}.

A quick example:

-----

#!/bin/sh

remove_bad_paths()
{
        badpaths="$@"; sedcmd="sed"

        for i in $badpaths; do
                sedcmd="$sedcmd -e 's|$i ||g'"
                sedcmd="$sedcmd -e 's|$i\$||g'"
                sedcmd="$sedcmd -e 's|$i/[^ ]*||g'"
        done

        eval $sedcmd
}

exec cc `echo "$@" | remove_bad_paths "-I/usr/pkg/include -L/usr/pkg/lib"`

-----

(Of course, this would be auto-generated by a make target somewhere in
bsd.buildlink.mk, with appropriately substituted values for ${LOCALBASE},
${CC}, ${SED}, etc.)

Benefits:

1) No need to grep package build logs for buildlink-dirty paths, then grovel
third-party makefiles and patch. Dirty paths automatically won't get passed
to the real compiler.

2) A package that sets USE_BUILDLINK_ONLY but isn't actually strongly
buildlinked will often fail to build. (Not always -- for example, a package
that uses curses but doesn't include devel/ncurses/buildlink.mk will still
find curses because it's in the default compiler path. But often.)

3) Making strongly buildlinked packages will be easier, so package
developers will be more inclined to do it.

Drawbacks:

1) Someone who doesn't know about this wrapper might be confused when build
output in strongly buildlinked packages occasionally doesn't correspond
exactly to the arguments passed to the compiler. The differences are small
and predictable, though, and we can document them in Packages.txt.

2) In strongly buildlinked packages, every call to ${CC} will be a bit
slower. However, pkgsrc already imposes a minor speed penalty on the process
of building from source, which itself isn't the fastest way to install
software. Which is fine by me -- our goal is to make it easy to install
software well, and measured in user time, we're speed demons. :-p

3) We have to make sure all callers of ${CC} find the wrapper instead of the
system compiler. ${BUILDLINK_DIR}/bin is prepended to $PATH in sub-makes. Is
this sufficient?

My opinion (naturally) is that the benefits are pretty sizable, and that the
drawbacks are more than worth the trouble (though I am worried about #3).
Thoughts?

- Amitai