summaryrefslogtreecommitdiff
path: root/mk/buildlink3/BUILDLINK3_DG
blob: 866ba4b85466cf3d3c9d339693b1a9b2a4b38345 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
$NetBSD: BUILDLINK3_DG,v 1.6 2004/09/21 15:01:40 jlam 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: I'm trying to bl3ify a package but I get an error that looks like:

	make: don't know how to make _BUILDLINK_USE. Stop

A1: You forgot to change a reference to a buildlink2.mk file into a
    buildlink3.mk file.


Q2: Dependencies are added for every single buildlink3.mk file I
    include, including for when it's supposed to use the base system
    software.  What's going on?

A2: You forgot to change USE_BUILDLINK2 to USE_BUILDLINK3 in the
    package Makefile.


Q3: Where can I see the actual command executed by the wrapper
    scripts?

A3: 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.


Q4: Why can't I check the values of variables set by the buildlink3
    framework using 'make show-var VARNAME=...'?

A4: Some variables are only defined for a subset of the package build
    phases.  Try instead:

	make show-var PKG_PHASE=wrapper VARNAME=...