The BUILD_DEPENDS dates back to September and so
libglade shared libraries from then need old (no longer existing)
libxml, pango, and gtk2 libraries.
I noticed this when installing packages on a machine that already had
the (what it thought was) correct dependencies.
libglade-2.3.6: 10-March-2004
- Implement support GtkComboBoxEntry, GtkToolItem, GtkToolButton,
GtkToggleToolButton, GtkRadioToolButton & GtkSeparatorToolItem (Damon
Chaplin)
- Fix automake warning (Steve Chaplin)
- Add libglade version number to the docs (Matthias Clasen)
- Fix usage of C++ keyword as an argument name (Bas Driessen)
- Allow additional signal parameter for glademm (Christof Petig)
- Support tooltips in toolbars (Michael Voigt)
libglade-2.3.2: 15-January-2004
- Support disambiguating msgids by prefixing them with a context
string. (Christian Stimming, Matthias Clasen)
libglade-2.3.1: 14-November-2003
- Register GtkColorButton, GtkComboBox, GtkFileChooser and
GtkFontButton types (Jonathan Blandford)
- Implemement support for GtkExpander (Mark McLoughlin)
- Fix memory leak and incorrect colour map usage (Morten Welinder)
- Win32 build support (Tor Lillqvist, Masahiro Sakai)
- Build fixes (James Henstridge, Michael Meeks)
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.
