that it can not be builtin. So also check for "This file is part
of the GNU C Library".
This helps with systems that have gettext(3) functionality
included in their glibc.
This also fixes build problem under Linux where devel/popt didn't
build "because some functions are defined both in gettext-lib and
in the native libc" as reported by minskim to tech-pkg on 21/Mar/2004.
by our native libintl. While it is not implemented, this allows us to build
programs against the native libintl, loosing very few functionality (some
translations of plural messages on few languages), and avoiding runtime
conflicts between native libintl and the gnu one (coming from the gettext
package).
Packages including .po files with uses of msgid_plural should define the
USE_MSGFMT_PLURALS variable to 'yes', so that the msgfmt wrapper is used.
(Do not use it when not really needed, as it will pull in perl5 as a build
dependancy).
dependencies unless USE_GNU_GETTEXT is defined or IMCOMPAT_GETTEXT is set
appropriately. This should allow packages to use the glibc gettext
routines on Linux.
by moving the inclusion of buildlink3.mk files outside of the protected
region. This bug would be seen by users that have set PREFER_PKGSRC
or PREFER_NATIVE to non-default values.
BUILDLINK_PACKAGES should be ordered so that for any package in the
list, that package doesn't depend on any packages to the left of it
in the list. This ordering property is used to check for builtin
packages in the correct order. The problem was that including a
buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed
from BUILDLINK_PACKAGES and appended to the end. However, since the
inclusion of any other buildlink3.mk files within that buildlink3.mk
was in a region that was protected against multiple inclusion, those
dependencies weren't also moved to the end of BUILDLINK_PACKAGES.
built-in or not into a separate builtin.mk file. The code to deal
checking for built-in software is much simpler to deal with in pkgsrc.
The buildlink3.mk file for a package will be of the usual format
regardless of the package, which makes it simpler for packagers to
update a package.
The builtin.mk file for a package must define a single yes/no variable
USE_BUILTIN.<pkg> that is used by bsd.buildlink3.mk to decide whether
to use the built-in software or to use the pkgsrc software.
as PREFER_PKGSRC. Preferences are determined by the most specific
instance of the package in either PREFER_PKGSRC or PREFER_NATIVE. If
a package is specified in neither or in both variables, then PREFER_PKGSRC
has precedence over PREFER_NATIVE.
BUILDLINK_PREFER_PKGSRC
This variable determines whether or not to prefer the pkgsrc
versions of software that is also present in the base system.
This variable is multi-state:
defined, or "yes" always prefer the pkgsrc versions
not defined, or "no" only use the pkgsrc versions if
needed by dependency requirements
This can also take a list of packages for which to prefer the
pkgsrc-installed software. The package names may be found by
consulting the value added to BUILDLINK_PACKAGES in the
buildlink[23].mk files for that package.
Makefiles simply need to use this value often, for better or for
worse.
(2) Create a new variable FIX_RPATH that lists variables that should
be cleansed of -R or -rpath values if ${_USE_RPATH} is "no". By
default, FIX_RPATH contains LIBS, X11_LDFLAGS, and LDFLAGS, and
additional variables may be appended from package Makefiles.
