wrapped version by full path. This fixes some cases where the wrappers
have been bypassed. lang/lua52 triggered the investigation as it failed
to link against libreadline, which should have been translated to
libedit. Tested by jperkin and myself with full bulk builds.
wrappers when USE_CWRAPPERS is enabled, saving a reasonable amount of
I/O during builds, mostly due to avoiding the transform/untransform sed
file generations.
WRAPPER_DIR and WRAPPER_BINDIR are used by various packages to override
or point to specific wrappers, and these now point to the cwrappers
directory when enabled, removing the need for CWRAPPERS_BIN_DIR
duplication and fixing packages which previously were using legacy
wrappers by accident.
A number of targets are now duplicated between bsd.wrapper.mk and
cwrappers.mk, the intention being that the legacy wrappers will be
deprecated once cwrappers is verified on all supported platforms. If
that turns out to take longer than expected, we will probably want to
introduce a wrapper.mk to abstract them away before loading the
appropriate back-end.
directories of the compiler/linker when using cwrappers. Command line
flags will often put them before the corresponding flags for
PREFIX/include and PREFIX/lib, so the version from outside .buildlink
would be prefered. The other way around is much less likely to be a
problem and normally the expected case. Bump required cwrappers version
for the necessary exact-match feature.
Motivation: with "USE_CWRAPPERS=yes" on the default case-insensitive
OS X filesystem, linking the wrappers was failing, stopping the
build. For example:
===> Creating toolchain wrappers for mess822-0.58nb3
ln: .../pkgsrc-current/mail/mess822/work/.cwrapper/bin/cc: File exists
*** Error code 1
Stop.
I never noticed this with the old wrappers, but they've also been
failing to link "CC" as an alias to "c++"; it's just that the failure
has been silent and I've never noticed a build failure for lack of
a "CC" wrapper, despite there probably never having been such a
wrapper.
Given that jperkin's SmartOS bulk build with this change produced
results similar to last week's non-cwrappers trunk build, we can
conclude that across platforms, the need for a "CC" wrapper is very
limited and we needn't try (and sometimes fail) to create one by
default.
