Long:
Some OS have libintl functionality in libc, so we do not necessarily
have to link against (a possibly non-existent) -lintl. For now, only
deal with Linux -- those who know for a fact which OS also behave
this way should adjust/add.
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.
rebuild the documentation database at install/deinstall time. This means
that:
- PLIST's do not need to call scrollkeeper-{update,rebuilddb} directly;
this is done by a bsd.pkg.install.mk template.
- The share/omf directory is only removed by scrollkeeper, which is the
last package in the dependancy tree.
- PKGREVISION is bumped.
Reviewed by wiz.
compiled using orbit-idl, which uses the C preprocessor to do its work, and
the C preprocessor has it's arguments transformed (correctly) by
buildlink2.
headers in ${BUILDLINK_DIR}, simply create BUILDLINK_CPPFLAGS.<pkg>
variables whose values are appended to CPPFLAGS, which are automatically
passed to the configure and build processes.
BUILDLINK_TRANSFORM.<pkg> has little use in buildlink2 since packages are
now told that the software may be found where it really is installed, not
in ${BUILDLINK_DIR} as was the case with buildlink1. Eventually, these
variables will be declared unsupported by buildlink2.
* Use *_CONFIG instead of directly invoking *-config so that the wrappers
will be used. This is also the correct way of invoking these scripts
anyway, but the GNOME authors keep making this same stupid mistake over
and over and over again ... <grrr>!
