to the stock libtool: you can now copy or symlink an uninstalled
libtool archive file somewhere else than its build directory, and you
can still link against it. This allows us to more easily bolt libtool
build machinery onto packages that have unusual(ly crappy) build
systems that rely on installing libraries to some common build directory
after they're built.
We do this by adding a "buildlibdir" variable to the uninstalled
libtool archive that points to the build directory of the archive.
Whenever we link against this archive, we rewrite the path to archive
on the libtool command line so that it points to the true archive.
This allows the real libtool to find the files under $buildlibdir/.libs.
from BUILDLINK_PACKAGES, which is built up by including buildlink[23].mk
files in the package's Makefile), and for each dependency, if it's
already installed, then automatically include the buildlink[23].mk
file for that dependency.
This means that for any package, the dependencies are taken to be the
union of the dependency information as laid out in /usr/pkgsrc and
the dependency information of installed packages stored in /var/db/pkg.
This handle situations where an installed package has _more_ dependencies
than the package as it exists in pkgsrc. This can occur, e.g., if
you build databases/gnome-libs with BDB_DEFAULT=db4, and then you
decide that you'd rather build other packages using the native Berkeley
DB, so you remove that setting from your environment. You'd still
like for your packages that depend on gnome-libs to also depend on
db4, but the pkgsrc Makefiles no longer reflect that dependency.
environment, it creates a Makefile fragment that is included within
bsd.buildlink3.mk that contains all of the buildlink3 variable
definitions that we want to pass to make(1) invocations on the same
package Makefile. Change the make variables that are only relevant
for the current package to use BUILDLINK_VARS instead of MAKEFLAGS.
This avoids overflowing the command line with lots of extra arguments.
by moving the inclusion of buildlink3.mk files outside of the protected
region. This bug would be seen by users that have set PREFER_PKGSRC
or PREFER_NATIVE to non-default values.
BUILDLINK_PACKAGES should be ordered so that for any package in the
list, that package doesn't depend on any packages to the left of it
in the list. This ordering property is used to check for builtin
packages in the correct order. The problem was that including a
buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed
from BUILDLINK_PACKAGES and appended to the end. However, since the
inclusion of any other buildlink3.mk files within that buildlink3.mk
was in a region that was protected against multiple inclusion, those
dependencies weren't also moved to the end of BUILDLINK_PACKAGES.
use-xpkgwedge systems. Not needed when building within pkgsrc, but useful
if you want to link outside 3rd-party software against pkgsrc-controlled
libraries.
in the fall-through code for setting a default value for USE_BUILTIN.<pkg>.
This provides ensures that USE_BUILTIN.<pkg> is always set for every
package listed in BUILDLINK_PACKAGES. Back out previous as it's now
unneeded.
add all of the direct _and_ indirect dependencies to the DEPENDS list.
This causes "install-depends" to check that every dependency, whether
it be direct or indirect, is up-to-date. This fixes PR 24721 by Jeremy
Reed.
native use the native, non-pkgsrc-managed X11R6
XFree86 use x11/XFree86-libs (not yet implemented)
xlibs use freedesktop.org xlibs (not yet implemented)
It is used to set the X11 implementation used to build X11 packages.
/usr/pkg/share/x11-links into the buildlink directory, just rely on the
regular buildlink3 infrastructure to do it for us. This simplifies the
handling of X11 in buildlink3. The only caveat is that "x11-links"
should appear at the head of BUILDLINK_PACKAGES, and this detail is
handled by x11-links/buildlink3.mk.
BUILDLINK_RPATHDIRS.<pkg> which is a list of directories relative to
BUILDLINK_PREFIX.<pkg> to add to the library runtime search path. For
packages that are a full dependency, this defaults to
BUILDLINK_LIBDIRS.<pkg>, but for packages that are a build dependency,
this defaults to an empty list (on the theory that a build dependency
doesn't have any shared libraries required by the package at runtime).
the dependency_libs line if it ended in a "-Ldir" option. Fix by not
eating shell word separators [ \`\"':;,]. This should fix PR 24639 by
Matthias Scheler.
renamed to {USE,IS}_BUILTIN and are handled separately by the builtin.mk
files.
Create a new variable PREFER.<pkg> that lets <pkg>/builtin.mk determine
what the preference is in a simple way.
USE_BUILTIN.<pkg> before it is checked. _BLNK_PACKAGES isn't strictly
a superset of _BLNK_DEPENDS due to the special x11-links handling
which should eventually be removed altogether.
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.
