author | Brian Utterback <brian.utterback@oracle.com> |
Fri, 03 Mar 2017 10:54:13 -0800 | |
branch | s11u3-sru |
changeset 7932 | c25424a2c03c |
parent 6035 | c9748fcc32de |
permissions | -rw-r--r-- |
3778 | 1 |
This is a guide to explain various useful variables in Userland component |
2 |
Makefiles. To distinguish these from the Makefile(s) that are part of each |
|
3 |
component distribution, the latter will be referred to as native Makefiles. |
|
4 |
||
5 |
The following are the basics that just about every Makefile should have. |
|
6 |
* COMPONENT_NAME is typically a short name (e.g., vim). |
|
7 |
* COMPONENT_VERSION is typically numbers separated by dots (e.g. 7.3). |
|
8 |
* COMPONENT_SRC is where the archive is extracted. A common value for this is |
|
9 |
"$(COMPONENT_NAME)-$(COMPONENT_VERSION)". |
|
10 |
* COMPONENT_PROJECT_URL is the general web site for the component. |
|
11 |
* COMPONENT_ARCHIVE is the base name of the archive to be downloaded. A common |
|
12 |
value for this is "$(COMPONENT_SRC).tar.gz". |
|
13 |
* COMPONENT_ARCHIVE_HASH is typically "sha256:" followed by the first output |
|
14 |
field of `sha256sum $(COMPONENT_ARCHIVE)`. |
|
15 |
* COMPONENT_ARCHIVE_URL is where the archive can be downloaded from. This is |
|
16 |
typically constructed from $(COMPONENT_PROJECT_URL) and $(COMPONENT_ARCHIVE). |
|
17 |
* COMPONENT_BUGDB is the lower-case rendering of the BugDB cat/subcat. |
|
3996
20c0f21bbe1e
15786608 SUNBT7162754 create new meta package developer/opensolaris/userland
Norm Jacobs <Norm.Jacobs@Oracle.COM>
parents:
3778
diff
changeset
|
18 |
* REQUIRED_PACKAGES is a list of packages required to build or run the |
20c0f21bbe1e
15786608 SUNBT7162754 create new meta package developer/opensolaris/userland
Norm Jacobs <Norm.Jacobs@Oracle.COM>
parents:
3778
diff
changeset
|
19 |
component and its tests. |
3778 | 20 |
|
21 |
These two are both initialized in make-rules/shared-macros.mk rather than any |
|
22 |
component-level Makefile, but are frequently referenced from the latter. |
|
23 |
* COMPONENT_DIR is the top-level directory of the given component in question. |
|
24 |
* SOURCE_DIR is set to $(COMPONENT_DIR)/$(COMPONENT_SRC). |
|
25 |
||
26 |
Additional pre/post configure, build, or install actions can be specified in |
|
27 |
a component Makefile by setting them in one of the following macros. None of |
|
28 |
these have default values. These are mostly used for miscellaneous set-up or |
|
29 |
clean-up tweaks as their names suggest. |
|
30 |
* COMPONENT_PRE_CONFIGURE_ACTION is used by several components to clone a |
|
31 |
source directory. |
|
32 |
* COMPONENT_POST_CONFIGURE_ACTION |
|
33 |
* COMPONENT_PRE_BUILD_ACTION |
|
34 |
* COMPONENT_POST_BUILD_ACTION |
|
35 |
* COMPONENT_PRE_INSTALL_ACTION |
|
36 |
* COMPONENT_POST_INSTALL_ACTION |
|
37 |
* COMPONENT_PRE_TEST_ACTION |
|
38 |
* COMPONENT_POST_TEST_ACTION |
|
39 |
||
40 |
If component specific make targets need to be used for build or install or |
|
41 |
test, they can be specified via the following. |
|
42 |
* COMPONENT_BUILD_TARGETS is not usually set because the default target of most |
|
43 |
open source software is the equivalent of a 'build' target. This needs to be |
|
44 |
set when building the software requires a different target than the default. |
|
45 |
You should not override make macros here, but in COMPONENT_BUILD_ARGS. |
|
46 |
* COMPONENT_INSTALL_TARGETS has a default value of "install". Very few |
|
47 |
components need to alter this. |
|
48 |
* COMPONENT_TEST_TARGETS has a default value of "check". Several components |
|
49 |
need to set this to "test". |
|
50 |
||
51 |
* COMPONENT_BUILD_ARGS is probably the mostly useful variable here for solving |
|
52 |
subtle build issues. When you need to override a MACRO set in the native |
|
53 |
Makefile of a component, do so by adding something like: |
|
54 |
COMPONENT_BUILD_ARGS += MKDIR="$(MKDIR)" |
|
55 |
Quoting is often important because values with white-space can be split up, |
|
56 |
yielding the wrong results. |
|
57 |
* COMPONENT_BUILD_ENV is for when you just need to override things in the |
|
58 |
calling environment, like PATH. |
|
59 |
* COMPONENT_INSTALL_ARGS is mainly used for altering target directories. |
|
60 |
* COMPONENT_INSTALL_ENV is mainly used for altering target directories. |
|
61 |
* COMPONENT_PUBLISH_ENV is so far only used to work around Python issues when |
|
62 |
used by "pkgdepend generate", though the variable may be extended in the |
|
63 |
future for general "gmake publish" usage. |
|
64 |
* COMPONENT_TEST_ARGS is little used. |
|
65 |
* COMPONENT_TEST_ENV is mainly used for altering PATH and friends. |
|
66 |
||
67 |
* COMPONENT_POST_UNPACK_ACTION is for making minor alterations to the unpacked |
|
68 |
source directory before any patching has taken place. It should almost never |
|
69 |
be used. |
|
70 |
* COMPONENT_PREP_ACTION is used to make alterations to the unpacked and patched |
|
71 |
source. It should be used with care. |
|
72 |
||
73 |
* CONFIGURE_DEFAULT_DIRS should be "yes" or "no". A value of "yes" (the |
|
74 |
default) will trigger the following being passed to CONFIGURE_OPTIONS as |
|
75 |
parameters to corresponding options. |
|
76 |
* CONFIGURE_BINDIR is the value for the --bindir= option. |
|
77 |
* CONFIGURE_LIBDIR is the value for the --libdir= option. |
|
78 |
* CONFIGURE_MANDIR is the value for the --mandir= option. |
|
79 |
* CONFIGURE_SBINDIR is the value for the --sbindir= option. |
|
80 |
* CONFIGURE_ENV is mainly used for passing CFLAGS and other common Makefile |
|
81 |
variables to configure. When should this be used as opposed to |
|
82 |
CONFIGURE_OPTIONS and COMPONENT_BUILD_{ARGS,ENV}? In general, you want |
|
83 |
to tell configure how to build the software using CONFIGURE_OPTIONS. But |
|
84 |
sometimes you need to pass values in via the calling environment. On rare |
|
85 |
occasions, you still need to do things like override MACRO settings in the |
|
86 |
generated Makefiles with COMPONENT_BUILD_ARGS. |
|
87 |
* CONFIGURE_LOCALEDIR is a cousin of the other *DIR variables above, but |
|
88 |
rarely used and hence not triggered by CONFIGURE_DEFAULT_DIRS. |
|
89 |
* CONFIGURE_OPTIONS is extremely useful, possibly our most used "add-on" |
|
90 |
variable, for passing various options to configure. These tend to vary per |
|
91 |
component, but --enable-foo and --disable-foo for various values of foo are |
|
92 |
quite common. |
|
93 |
* CONFIGURE_PREFIX is the prefix for the various *DIR variables above. Its |
|
94 |
default is "/usr"; set it if some other value (e.g., "/usr/gnu") is needed. |
|
95 |
* CONFIGURE_SCRIPT should be set if the default "$(SOURCE_DIR)/configure" is |
|
96 |
unsuitable for whatever reason. |
|
97 |
||
98 |
* studio_OPT has a default value of "-xO4". Occasional bugs in the optimizer |
|
99 |
have been found which have required altering this to "-xO3". There are also |
|
100 |
studio_OPT.$(MACH).$(BITS) versions of this available if greater specificity |
|
101 |
is needed. |
|
102 |
||
103 |
* TPNO is the Third Party number (i.e., a numeric value): the License |
|
104 |
Technology from the Product Lifecycle Suite tool. This should be used |
|
105 |
in the common case when there is just one TPNO for a component. We |
|
106 |
recommend that this be near the top of any Makefile, just below the |
|
107 |
various COMPONENT_foo definitions. |
|
108 |
* TPNO_foo is for the rare case (~3% of components) when a component has |
|
109 |
more than one TPNO. Each one should have a separate short but descriptive |
|
110 |
name substituted for "foo". This likewise should be near the top of any |
|
111 |
Makefile, just below the various COMPONENT_foo definitions, and it must |
|
112 |
also be before the inclusion of ips.mk . |
|
6035
c9748fcc32de
PSARC 2015/535 OpenStack service updates for Kilo
Devjani Ray <devjani.ray@oracle.com>
parents:
3996
diff
changeset
|
113 |
* PKGREPO_REMOVE_BEFORE_PUBLISH allows automatic removal of previously |
c9748fcc32de
PSARC 2015/535 OpenStack service updates for Kilo
Devjani Ray <devjani.ray@oracle.com>
parents:
3996
diff
changeset
|
114 |
published components from PKG_REPO (including obsolete and renamed |
c9748fcc32de
PSARC 2015/535 OpenStack service updates for Kilo
Devjani Ray <devjani.ray@oracle.com>
parents:
3996
diff
changeset
|
115 |
versions). When set as PKGREPO_REMOVE_BEFORE_PUBLISH=yes removal |
c9748fcc32de
PSARC 2015/535 OpenStack service updates for Kilo
Devjani Ray <devjani.ray@oracle.com>
parents:
3996
diff
changeset
|
116 |
occurs immediately prior to pkgsend. default: "no" |
c9748fcc32de
PSARC 2015/535 OpenStack service updates for Kilo
Devjani Ray <devjani.ray@oracle.com>
parents:
3996
diff
changeset
|
117 |
|
3778 | 118 |
|
119 |
--- |
|
120 |
||
121 |
Now switching from explaining the function of specific variables to a more |
|
122 |
general discussion about how to use them to solve problems. One method that |
|
123 |
has served time and again is adding a level of indirection. For example, |
|
124 |
when Python 3 came along, we decided to build it 64-bit only, which meant |
|
125 |
its various modules also needed to be built 64-bit only. But many of them |
|
126 |
had BUILD_32_and_64 in their native Makefile. So how to tweak that macro |
|
127 |
to do one thing for Python 2.x but another for 3.x? JBeck spent an entire |
|
128 |
day trying various combinations that seemed right, but none of them worked. |
|
129 |
Then Norm pointed out that changing PYTHON_VERSIONS from "3.4 2.7 2.6" to |
|
130 |
$(PYTHON3_VERSIONS) and $(PYTHON2_VERSIONS) which in turn were "3.4" and |
|
131 |
"2.7 2.6" would do the trick. I.e., adding a level of indirection solved |
|
132 |
the problem, as it allowed $(PYTHON_VERSIONS) to be used to specify 64-bit |
|
133 |
macros but $(PYTHON2_VERSIONS) to specify 32-bit macros. There are many |
|
134 |
other places where constructs like this are used. |