October 23rd, 2002, 02:30
Anyone out there know how to use the MULTI_PACKAGES option or the SUB_PACKAGE option in the ports system? A quick example would be great if anyones used it.

I know the FLAVORS option is used in the following manner:


testbox# make show VARNAME=FLAVORS

testbox# env FLAVORS="option1, option2" make install


is it the same with MULTI_PACKAGES, or SUB_PACKAGE ?


October 23rd, 2002, 16:05
Never used it, and the bsd.port.mk man page doesnt help all that much either..


Starting with OpenBSD 2.7, each port can generate several packages
through two orthogonal mechanisms: FLAVORS and MULTI_PACKAGES.

If a port can be compiled with several options, set FLAVORS to the list
of possible options in the Makefile. When building the port, set
FLAVOR='option1 option2...' to build a specific flavor of the port. The
Makefile should test the value of FLAVOR as follows:

.if ${FLAVOR:L:Moption1}
# what to do if option1
.if ${FLAVOR:L:Moption2}
# what to do if option2

bsd.port.mk takes care of a few details, such as generating a distinct
work directory for each flavor, or adding a dash separated list of op-
tions to the package name. The order in which FLAVOR is specified does not matter: the generated list, called the canonical package extension, matches the ordering of FLAVORS. Also, it is an error to specify an option in FLAVOR that does not appear in FLAVORS.

In recursive package building, flavors can be specified as a comma separated list after the package directory, e.g., SUBDIR+=vim,no_x11.

Finally, packing information will use templates with the canonical pack-
age extension if they are available: if FLAVOR='option1 option2' and both
COMMENT and COMMENT-option1-option2 are available, COMMENT-option1-op-
tion2 will be used.

If a port can generate several useful packages, set MULTI_PACKAGES ac-
cordingly. Each extension of a MULTI_PACKAGES name should start with a
dash, so that they cannot be confused with FLAVORS. In dependency check-
ing and recursive builds, a subpackage can be specified after a comma,
e.g., SUBDIR+=quake,-server. MULTI_PACKAGES only affects the actual
package building step (and the describe step, since a MULTI_PACKAGES port
will produce several descriptions).

If MULTI_PACKAGES is set, each element of MULTI_PACKAGES triggers a re-
cursive make package, with SUBPACKAGE set to the right value, and PACKAG-
ING defined. For instance, if MULTI_PACKAGES=-lib -server, make package
will work as follows:

o Run env SUBPACKAGE= PACKAGING= make package,
o Run env SUBPACKAGE=-lib PACKAGING=-lib make package,
o Run env SUBPACKAGE=-server PACKAGING=-server make package,

The port's Makefile can test the value of SUBPACKAGE to specialize pro-
cessing for all sub packages. Note that SUBPACKAGE can also be set for
dependency checking, so be careful to also test PACKAGING: the build
stage is shared among all subpackages, and tests often only make sense
during the packaging stage. All packing information is derived from tem-
plates with SUBPACKAGE appended. In the preceding example, the packing-
list template for pkgname-foo must be in PLIST-foo.

October 23rd, 2002, 16:50
yeah I saw that online but unfortunately for me that doesn't seem to be any clearer, there's been a lot of discussion on ports@ about this but all from a programmers perspective, which is what this seems to be, although I do think I have figured this out.

Basicly a make followed by a make install produces all packages or SUB_PACKAGES and places them into


then just a package add from there. From what I can tell there is no way to just install one or two of the packages without doing this. Oh Well.