Created attachment 361506 [details, diff] graphite2-1.2.1.ebuild.patch Dependency of GTK+ via pango and harfbuzz. The Perl part is a bit hacky because perl-module.eclass breaks if you try to run it twice (for two arches). But then, presumably we don't need a non-native version of the Perl module anyway.
Created attachment 366502 [details, diff] Patch to graphite2-1.2.1.ebuild, using cmake-multilib.eclass @Andrew: please use multilib_build_binaries instead of multilib_is_native_abi. Your patch is esentially correct. However, in this particular case cmake-multilib.eclass should be much easier to use. I've also removed the ugly base.eclass inherit in favor of own cmake-utils functions... The remaining part is tests. Curious enough, most of the tests don't have extra dependencies. The only tests that have those are the 'comparison tests' which seem to compare graphite2 to other libraries. Since the tests are skipped appropriately when necessary libs aren't installed, I'd say we can just leave them at native ABI with a comment. As for those tests themselves, the dependency string in ebuild is incomplete or outdated. Reading the sub-CMakeLists.txt file, I can find at least a few more libraries like icu and harfbuzz. Since those tests are pretty specific and I wouldn't consider them a core part of the test suite. Since they compare the library to other libraries on the system, I'd say their results aren't 100% safe. I think we can either: a) don't put any deps for those tests and just have them run when user has some of those libraries installed, b) put one big || () dep on necessary libraries, so that we'd run at least 1 comparison test but not pull in too many extra deps, c) put all deps in there. This would mean that users running tests will have a few extra libraries installed but it would be tested against each of them :).
Thanks for the comments. Regarding tests, I'd agree that comparisons with other libraries aren't particularly meaningful so it's probably not worth adding deps for them. (Plus, harfbuzz depends on graphite2 so it would have to be left out anyway.) That said, I have zero personal investment in graphite2 so I may not be the best person to judge -- to me it's just another package on the path to GTK+ multilib. (:
The patch looks nice and clean.
ping @ openoffice!
+*graphite2-1.2.4-r1 (01 Mar 2014) + + 01 Mar 2014; Michał Górny <mgorny@gentoo.org> +graphite2-1.2.4-r1.ebuild: + Introduce multilib support as a dependency of pango, bug #488860. Committed p.masked, feel free to comment before it is unmasked.
