r102562 and #34056 wrt 10.5 pango +universal

[Ryan Schmidt]

On Feb 11, 2013, at 21:39, Jeremy Lavergne wrote:

>> Before you try an older pango, just remove the graphite2 dependency from harfbuzz; it's optional.
> 
> Well, pango also depends on graphite2. Can it be removed from pango as well as harfbuzz?

I don't think pango uses graphite2; pango uses harfbuzz which uses graphite2. The graphite2 dependency was added to pango only because of my misunderstanding of dynamic libraries; the correct fix was not to add the graphite2 dependency to pango but to fix the .la files installed by all ports, which is now done in MacPorts base in trunk. See the recent "icu 50" discussion thread and ticket #38010.


>> Can the muniversal portgroup help?
> 
> I'm not sure (never really made use of muniversal before).

And you've been here how long? :)

muniversal builds for each arch separately, then lipo's the results together. If the cmake portgroup has the limitation that there cannot be an i386 ppc universal build (which I had not remembered), then using muniversal should work around that problem, at the expense of longer build times and possible additional build problems, depending on the port.


> Though I do notice it could use some updating on its list of ${configure.compiler}:
> http://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl#L59

Presumably proc muniversal_arch_flag_supported should be removed; isn't there already a proc in base that does this?


>> Can depends_skip_archcheck help?
> 
> This sounds ideal, since graphite2 is pulled in both by harfbuzz and pango itself. Simply having an build tool operate is all that's really needed. I'll explore this one immediately, but feel free to explain how muniversal could be employed in this instance.