Hi,
> Maybe it's just gimp-perl then. Maybe it's the fact that gimp-perl simply
> relies on all symbols, while gimp-print probably only relies on the most
> common (&small) subset. In that case, most probably only gimp-perl is hurt...
> Which might also be the only plug-in where the community has considerable
> need to be convinced that a new version of some tool is as stable as the old
> one (because people's income depends on working servers) before they switch.
>
> Anyway, I *did* switch to the new API before writing my lament. I wrote
> that mail because I *do* think such an under-the-hood-change deep *within*
> the feature freeze is highly unconventional.
Marc, believe me or not, but there was no great API change. The symbols
gimp-perl used to use have been mapped to the new API until recently by
defines and typedefs in gimpcompat.h and gimpenums.h. Now these defines
are disabled by default and you can turn them back on with a small change
to your Makefile. The number of symbols you use from that set should be
totally irrelevant.
Maybe your problems to get gimp-perl going with GIMP_ENABLE_COMPAT_CRUFT
defined were related to the fact that gimp-perl seems to prefer to use
installed libgimp header files over the current ones in the source tree.
Salut, Sven
