use LIBTOOL_OVERRIDE. In the buildlink[23] case, that is supposed to be
the one in ${BUILDLINK_DIR}. Create new private variables _LIBTOOL and
_SHLIBTOOL to hold these paths.
building of software. For packages that use either buildlink2 or
buildlink3, this would be the wrapper script in ${BUILDLINK_DIR}.
* Garbage-collect _BLNK_WRAP_SETENV.* as those are not needed after
the above changes. Configure and make processes will automatically
find the right compilers in the PATH.
* PKGLIBTOOL and PKGSHLIBTOOL are no longer needed since LIBTOOL and
SHLIBTOOL point to the correct libtools regardless of any
USE_BUILDLINK[23] definitions.
due to a type on gcc.mk that causes the ${_GCC_PREFIX}/bin to always be
prepended to the PATH. The problem that was hiding was "make" resolving
to ${TOOLS_DIR}/bin/make if the package used GNU make, which broke
building since the package Makefile is a BSD Makefile and we passed
PATH to some phases of the build. Fix this by expanding MAKE to the
full path to ${MAKE} in bsd.prefs.mk. We also garbage collect the now
useless checks for PHASES_AFTER_BUILDLINK that cluttered the PREPEND_PATH
code.
(by checking PREPEND_PATH) and only for those phases of the build that
care about the PATH (buildlink or later). We also pass the PATH to
those same phases of the build so that executing ${CC} will work correctly
from custom {pre,do,post}-* targets that occur at buildlink time or
later.
just assume they do unless they're known _not_ to work. So far, only
Darwin-5.* suffers from this problem, apparently because they use some
bizarre version of zsh for /bin/sh.
fine-grained distinction between required versions of pre-requisites
(DEPENDS) and versions that are recommended for security or library ABI
consistency reasons (RECOMMENDED).
The contents of ${RECOMMENDED} are added to DEPENDS unless
IGNORE_RECOMMENDED is set to YES, in which case a warning will be printed
and IGNORE_RECOMMENDED will be added to BUILD_DEFS.
Add a corresponding BUILDLINK_RECOMMENDED.<pkg> variable for use with
buildlink2 and buildlink3.
Changes include supporting XFree86-4.3.99.14 aka XFree86-current.
Added some new library versions and some freetype2 include files.
And bump the required version number in the bsd.buildlink mk's.
well as stripping -L to subdirs of these directories from dependency_libs
lines in *.lai files. This corrects the changes in revision 1.18 of this
file and restores some functionality accidentally removed in version 1.19
of this file. Should fix the subversion buildlink/libtool problem
reported on tech-pkg@.
thing.
(*) Move the code to adjust Makefiles to refer to the correct
PKGLOCALEDIR into bsd.pkg.mk and reimplement it using subst.mk so
that it's non-USE_BUILDLINK2 packages can use it, too.
(*) Reimplement the PKGCONFIG_OVERRIDE code in bsd.pkg.mk using subst.mk.
(*) Reimplement the unbuildlink code in bsd.buildlink2.mk using subst.mk.
put the tools in ${WRKDIR}/.tools/bin instead of in ${BUILDLINK_DIR},
and remove the need for buildlink2 to use USE_GNU_TOOLS. In the
modified USE_GNU_TOOLS implementation, the following implementation-
specific variables have the following meanings:
_TOOLS_REPLACE.<tool>
means that we want ${AWK}, ${SED}, etc. symlinked into
${TOOLS_DIR} as awk, sed, etc.
_TOOLS_NEED_GNU.<tool>
means that we want to use the pkgsrc version of <tool>
symlinked info ${TOOLS_DIR} as awk, sed, etc. If this is
"YES", then it always trumps _TOOLS_REPLACE.<tool>.
And we want nothing to happen if we're building the pkgsrc GNU tool
itself. The modified USE_GNU_TOOLS implementation should also
hopefully fix the circular dependency problem.
Create a new target "tools" that is run after "patch" and before
"buildlink" that populates the ${TOOLS_DIR} directory. This ensures
that it's always run at the right time, instead of relying on
pre-buildlink or pre-configure, which may be cancelled by
NO_BUILDLINK or NO_CONFIGURE.
XXX There is some possible fallout in texinfo.mk with the MAKE_ENV and
XXX CONFIGURE_ENV settings for INSTALL_INFO and MAKEINFO. It looks
XXX like the MAKE_ENV and CONFIGURE_ENV settings should move from
XXX tools.mk into texinfo.mk, and they no longer need to be
XXX conditional on USE_BUILDLINK2. I'll leave it to the texinfo.mk
XXX dude (Hi, Stoned!).
INFO_FILES is now defined by default to the empty value.
If it is not empty it means that install-info -or a suitable
replacement like pkg_install-info- is required.
USE_MAKEINFO is now defined by default to the 'no' value.
If it has any other value it means that makeinfo is required.
Note that as before simply defining USE_MAKEINFO in a package
Makefile is enough to trigger the use of makeinfo. I.e. it is not
required to be '[yY][eE][sS]'.
As a side effect when using buildlink2 always create install-info and
makeinfo wrappers in ${BUILDLINK_DIR}/bin. This could help
package maintainer to catch spurious/hidden install-info and makeinfo
usage.
Note that for now this nice feature is not really enabled as the relevant
part of bsd.buildlink2.mk is still conditional upon USE_NEW_TEXINFO.
It will really be when USE_NEW_TEXINFO will be removed from pkgsrc.
when a package use the buildlink2 framework but does not define
USE_MAKEINFO. Well it was not after all.
This caused annoying messages because missing's commands emit annoying error
messages when the script is invoked with only 'makeinfo' as argument
(typically run this way by configure scripts). And more it does not
handle makeinfo's '--output=...' argument.
I first thought that it could be used as a nice way to get ride of the need
for makeinfo when it was only dubiously run during build or installation
of a package. But it also has the annoying behavior of creating empty files
because of the typical automake generated Makefile target for info file
build.
Making the buildlink2's makeinfo hiding script only logging an error
and doing 'exit 1' is actually a better tool to spot the need for makeinfo.
makeinfo commands.
The goal of the new framework is twofold:
- reduce the number of '@exec' and '@unexec' in PLIST by
using INSTALL/DEINSTALL scripts to handle entries addition/removal
Info directory file.
- achieve lighter dependencies by avoiding unnecessary run-time
dependency on the gtexinfo package and if needed with the help of the
standalone install-info command provided by the recently imported package
pkgtools/pkg_install-info.
A package must be sightly updated to use this new framework and
must define the variable USE_NEW_TEXINFO. This variable will
be removed from the pkgsrc tree when all package would have been
updated.
For details see section 10.24 of Packages.txt, comments in
mk/{texinfo.mk,buildlink2/bsd.buildlink2.mk} and upcoming mail to
<tech-pkg at netbsd dot org>.
followup to PR pkg/20529:
Some libraries (in this example, a given Linux's native libpthread) don't
come with a version number at all and/or are in fact symlinks. Test for
this and act accordingly in fake-la.
This allows packages that use pthread to buildlink under various Linuxen.
Should close PR pkg/20529 and PR pkg/21854. Thanks, Joachim.
On solaris for instance if one put /usr/lib in their path before /usr/ccs/bin
it would match /usr/lib/ld rather than /usr/ccs/bin/ld except that
/usr/lib/ld is a directory...
dependency_libs definitions in *.lai files. This should remove another
instance that can cause "buildlink2 leakage" into installed files under
${LOCALBASE}.
