changes to the buildlink3 framework. The changes ensure that
BUILDLINK_PACKAGES orders packages so that for any element in the
list, the packages to the right do not depend on any packages to the
left of that element.
http://fink.sourceforge.net/doc/porting/shared.php
It's okay to link against a name like "libqt.2.3.0.dylib" using
"-lqt.2.3.0", which means we never need to do anything more than just
strip the trailing ".dylib" from shared library names when converting from
a full path to "-L... -l...". This should fix PR 24402.
${LOCALBASE}. Some packages' configure scripts resolve all paths to
physical paths, and since buildlink3 suppresses references outside of
${LOCALBASE}, it can break the build of those packages.
This should fix the problem noted by Nathan Williams in the thread
titled "x11/tk build failure" at:
http://mail-index.netbsd.org/tech-pkg/2004/02/17/0004.html
Package Makefiles may now directly include compiler.mk.
* Don't include compiler.mk within bsd.prefs.mk any longer. It was only
included for the purposes of defining CC_VERSION. Packages that want
to test the value of CC_VERSION should now first include
"../../mk/compiler.mk". Any GCC_REQD statements in package Makefiles
should be set before compiler.mk is included.
* Simpllfy pkgsrc/mk/compiler/*.mk files as a result of not needing to
be included indirectly by bsd.prefs.mk. We remove the special handling
associated with detecting whether the file was included from within
bsd.prefs.mk. These files are now much more straightforward to write
and understand.
* G/C the BSD_PREFS_MK stack mechanism as the only users (compiler/*)
no longer need it.
* Ensure that directories are prepended to the PATH only from within
bsd.pkg.mk.
pkg-config to only look in ${BUILDLINK_DIR}/lib/pkgconfig for *.pc files.
This will correctly hide the presence of software from configure scripts
that query pkg-config for that information.
Idea suggested by Julio M. Merino Vidal.
compiler set. This will cause the libtool configuration found in several
packages to use the correct C++ compiler even though the package doesn't
use C++. This was causing bugs when CXXFLAGS contained flags not
understood by the system gcc-2.95.3.
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.
BUILDLINK_PREFER_PKGSRC
This variable determines whether or not to prefer the pkgsrc
versions of software that is also present in the base system.
This variable is multi-state:
defined, or "yes" always prefer the pkgsrc versions
not defined, or "no" only use the pkgsrc versions if
needed by dependency requirements
This can also take a list of packages for which to prefer the
pkgsrc-installed software. The package names may be found by
consulting the value added to BUILDLINK_PACKAGES in the
buildlink[23].mk files for that package.
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.
packages which pass these gcc-specific flags.
also ignore -Werror; if a package passes -Werror, it's expecting that
the compiler is gcc, which in this case it is not. SunPro often emits
warnings on code which gcc doesn't, so transforming this flag to
-errwarn is counterproductive.
