fe3c1321bf
to tech-pkg: ===== * USE_BUILDLINK3=YES will be unconditional. (In fact, USE_BUILDLINK3 will be ignored altogether by mk/; but see below.) * NO_BUILDLINK and NO_WRAPPER will be ignored by mk/. If a build happens, these phases will happen. * The existing NO_BUILD will imply the previous NO_BUILDLINK and NO_WRAPPER. If no build happens, those phases are not needed. * NO_TOOLS will be ignored by mk/. The tools phase, which provides much more than just the C compiler, will always happen regardless of package. This will make metapackage builds only slightly slower, in trade for far less user error.
77 lines
3 KiB
Text
77 lines
3 KiB
Text
$NetBSD: BUILDLINK3_DG,v 1.7 2005/03/24 17:46:01 tv Exp $
|
|
|
|
0 Developer's guide to buildlink3
|
|
=================================
|
|
|
|
This is a tutorial for pkgsrc developers to understand and to use the
|
|
buildlink3 framework in pkgsrc.
|
|
|
|
|
|
1 Changes between buildlink2 and buildlink3
|
|
===========================================
|
|
|
|
The buildlink3 framework is a evolutionary descendant of the
|
|
buildlink2 framework that does a better job of adhering to the
|
|
fundamental buildlink principle: only allow the software build
|
|
process to see what we choose to allow it to see.
|
|
|
|
|
|
1.1 Better behavior with libtool
|
|
================================
|
|
|
|
One of the biggest problems in buildlink2 is handling packages that
|
|
install libtool archive files for libraries that are also present in
|
|
the base system. buildlink3 is significantly better at this as it
|
|
more tightly controls where libtool can find libtool archives. One
|
|
side effect of this is that we no longer need to create fake libtool
|
|
archives to work around cases where the pkgsrc libraries were being
|
|
used instead of the system libraries if they shared the same name.
|
|
|
|
|
|
1.2 New buildlink3.mk file structure
|
|
====================================
|
|
|
|
buildlink3.mk files have two major differences over buildlink2.mk
|
|
files. The first, most noticeable difference is that buildlink3.mk
|
|
generally don't contain a BUILDLINK_FILES definition. This is
|
|
because buildlink3 automatically determines which files to symlink
|
|
into ${BUILDLINK_DIR} by examining the PLIST of the installed package.
|
|
The second difference is that buildlink3.mk files keep track of how
|
|
"deep" we are in including buildlink3.mk files, and only creates
|
|
dependencies on packages encountered at depth 1. This means that
|
|
packages that want to add a dependency must directly include the
|
|
buildlink3.mk file for that dependency.
|
|
|
|
|
|
1.3 Support for pkgviews
|
|
========================
|
|
|
|
When building pkgviews packages, buildlink3 doesn't symlink files
|
|
into ${BUILDLINK_DIR} since it can safely refer to only a specific
|
|
package's files by passing the appropriate -I<dir> and -L<dir> flags
|
|
to the compiler, where <dir> points to a location in the package's
|
|
depot directory. When building "overwrite" packages, buildlink3 will
|
|
act and feel very much like buildlink2 but with more advanced wrapper
|
|
scripts, and there are provisions for allowing an "overwrite" package
|
|
to build against the viewed instance of a depoted package.
|
|
|
|
|
|
2 Troubleshooting
|
|
=================
|
|
|
|
Q1: Where can I see the actual command executed by the wrapper
|
|
scripts?
|
|
|
|
A1: You should examine the contents of the ${WRKDIR}/.work.log file.
|
|
The lines preceded with [*] are the commands that are intercepted
|
|
by the wrapper scripts, and the lines preceded with <.> are the
|
|
commands that are executed by the wrapper scripts.
|
|
|
|
|
|
Q2: Why can't I check the values of variables set by the buildlink3
|
|
framework using 'make show-var VARNAME=...'?
|
|
|
|
A2: Some variables are only defined for a subset of the package build
|
|
phases. Try instead:
|
|
|
|
make show-var PKG_PHASE=wrapper VARNAME=...
|