it for plurals support, but that is already handled correctly (FSVO
"correctly") by the pkgsrc/mk/tools/msgfmt.sh script.
Also remove _USE_GNU_GETTEXT definitions from pkgsrc/mk/platform/*.mk
files as that value has been unused by pkgsrc for quite some time
(going back several branches).
for manipulating PLISTs. This module is not used by default pending
more widespread testing -- currently the variable _USE_PLIST_MODULE
must be defined in /etc/mk.conf to enable its use.
The main features of the new PLIST module are:
(1) Splits out the PLIST-handling code from bsd.pkg.mk into a
separate "plist" module.
(2) Splits out giant, multi-line awk scripts stored in make
variables into separate awk scripts that may be joined
together to post-process PLISTs. Each of these awk scripts
consolidates the processing for one set of files, e.g.,
man pages, info pages, etc., and is more easily commented
than a make variable.
(3) Splits out the print-PLIST code from the regular PLIST code
since they have no common pieces (print-plist.mk vs.
plist.mk).
(4) Completely re-implements the shared-library handling to be
more efficient. Along the way, this also fixes a problem
for Mac OS X users where the PLISTs incorrectly contained
absolute paths.
(5) Completely re-implements the info-file handling so that we
can migrate from INFO_FILES definitions to just adding
info/foo.info entries in the static PLISTs.
(6) Adds commented-out support for automatically compressed or
decompressed info page entries based on the value of MANZ.
These changes will be activated after texinfo.mk has been
replaced by something that is built using the more modern
primitives now available in pkgsrc.
(7) Move the file compression logic into a separate script
"doc-compress" that compresses or decompresses files while
minding symlinks. This script is now called by bsd.pkg.mk
to do the "autmoatic man page handling". In the future,
it will also handle the "automatic info page handling" and
possible others.
In general, the idea is to move stuff out of the Makefiles and into
separate files where we don't need to worry about quoting rules
and where each file can have a separate history of commits. This
simplifies the makefile logic (especially in terms of readability)
and also simplifies maintenance of the code.
not on by default). Separate out the variable defintions that are
now made by the new tools framework. Some of the trickier platforms
(AIX, IRIX, Interix, OSF1) still need more work.
a mistake to include "GZIP" as an ${OPSYS}-specific variable as there
is nothing ${OPSYS}-specific there to tune. Define GZIP in
defaults/mk.conf instead, and remove the definition from each of the
existing platform/${OPSYS}.mk files.
possible, just for the sake of doing so, is not a good thing to do:
The platform files define _STRIPFLAG_* to determine whether to strip things.
But since this is included in bsd.prefs.mk, ".if ..." checks cannot take
things set in the Makefile into account. So convert INSTALL_UNSTRIPPED=YES
to a defined/undefined variable check in bsd.pkg.mk, and use the :D:U idiom
in the _STRIPFLAG_* variables.
This should fix PR pkg/28772 and PR pkg/29031.
Convert _OPSYS_MAX_CMDLEN to a plain _OPSYS_MAX_CMDLEN_CMD variable, which
is not evaluated by a shell until CONFIGURE_ENV is expanded (and only then
if USE_LIBTOOL+GNU_CONFIGURE are both set).
and groupadd commands won't follow the calling conventions of the
NetBSD useradd/groupadd. Modify the INSTALL scripts to *never* create
users or groups if there is no available ${USERADD} or ${GROUPADD}
command, but will warn the user of users and groups that need to be
created before the package can be installed.
(1) defs.${OPSYS}.mk --> platform/${OPSYS}.mk.
The "platform" subdirectory is where all of the ${OPSYS}-specific
infrastructure logic should reside.
(2) bsd.pkg.defaults.mk --> defaults/mk.conf
bsd.pkg.obsolete.mk --> defaults/obsolete.mk
Renaming bsd.pkg.defaults.mk to defaults/mk.conf is to mimic the way
that NetBSD has /etc/rc.conf as well as /etc/defaults/rc.conf, where
the latter is a full list of user-settable variables, and the two
files share the same name to reinforce the fact /etc/defaults/rc.conf
can be directly copied in place as /etc/rc.conf. This is the same
relationship shared by defaults/mk.conf and /etc/mk.conf.
