Portfile cached on repetitive builds??

[Ryan Schmidt]

On Aug 4, 2008, at 03:31, Harry van der Wolf wrote:

> Ryan Schmidt wrote:
>
>> On Aug 3, 2008, at 10:52, Harry van der Wolf wrote:
>>
>>> I'm working on the pango Portfile to make it a real two-step  
>>> Universal compilation.
>>
>> What is the matter with pango +universal the way it works now?
>
> Pango is "ENDIAN" dependent and was built incorrectly within  
> MacPorts (just as Gtk).

How do you know pango was built incorrectly? What was the symptom?  
For gtk2, I recall the symptom was that gtk2 would not build at all  
on PowerPC Macs when glib2 2.16.4_0 or glib2-devel 2.17.3_0 was  
installed in its broken universal state.

http://trac.macports.org/ticket/15816

> Maybe it is now builing correctly as a universal librarary now that  
> glib2 has been (apparently) solved.

Yes, please make sure you are testing pango and gtk2 built against  
glib2 2.16.4_1 or later (or glib2-devel 2.17.3_1 or later). I hope  
the glib2 problem is not merely apparently solved but definitely  
solved. You can look at the changes that were made here and evaluate  
whether you believe they should fix the problem completely or not.

http://trac.macports.org/changeset/38288

> I decided to make it a two way ppc and i386 build and merge it with  
> lipo to universal (like cairo is done).

At this time, I believe only openssl and cairo use this technique,  
because they require it. But the vast majority of software should  
support the "normal" all-at-once universal build that MacPorts  
implements by default. Not sure what the story is with openssl. With  
cairo, it uses autoconf to detect endianness, and this did not work  
properly for an all-at-once universal build, as discussed in this  
thread:

http://lists.cairographics.org/archives/cairo/2007-February/009523.html

The developers of cairo elected not to make any changes to their  
source code in response to this, so a multi-step universal build was  
the only option. But see below regarding autoconf 2.62.

MacPorts trunk has a "merge" procedure which should make multi-step  
universal builds easier. We cannot use that yet in released ports  
because MacPorts 1.7.0 has not yet been released, but you could use  
it for your testing if you want.

> A universal build that is directly using "-arch ppc -arch i386" in  
> one step is always using (AFAIK) the endianness of the build platform.

I cannot substantiate that claim. Software that checks endianness at  
configure time could have problems, yes; software developers are  
advised to check endianness at compile time instead. That's what the  
patch to glib2 fixed. But even for software that checks endianness at  
configure time (and I'm not sure if that applies to pango), I have  
been told (by the developers of libtiff) that autoconf 2.62 includes  
fixes for its endian detection that support all-at-once universal  
builds. It's possible pango and other software has already known how  
to deal with this even before autoconf 2.62. And if not (like cairo),  
it's possible that an autoreconf with autoconf 2.62 (which is already  
available in MacPorts) will fix the problem. However I may not use  
this for cairo even if it does work; see below regarding --enable- 
quartz-font.

> A two-way step is (most of the time) doing that correct   
> (especially now that glib2 is apparently fixed which was also a big  
> problem).

Yes, but multi-step builds take more time to do and I believe the end  
product may take more disk space. (Note that it's not always  
necessarily two steps; the user could set ${universal_archs} to up to  
four architectures.)

There is one benefit to multi-step universal builds however: you can  
use different options for different architectures. This will be  
necessary in cairo, as the --enable-quartz-font option cannot be used  
on 64-bit architectures:

http://trac.macports.org/ticket/16007

> The plan was to build pango with "standard" Macports, use that in  
> the avidemux application bundle. Then compile it again using my  
> "two-step" compilation Portfile and make a second application  
> bundle and let "my" ppc users test.

It would certainly be good to get some real feedback on whether it  
works or not. If a standard MacPorts universal build of pango does  
not work, then please try running autoreconf with autoconf 2.62 first  
and see if that helps.

> If you are sure that pango is built correctly (e.g. little_endian  
> for intel and big_endian for ppc), I will drop my attempts  
> immediately. Pango was just on my way to test gtk for correct  
> universal build (w.r.t. endianness)

I'm not sure pango builds correctly universal, particularly because  
my cairo is not universal yet and pango depends on cairo. But with  
the tips I've gotten from you and others in the several open tickets  
relating to cairo universal builds (#15451, #15570, #16007, possibly  
#13971) I am fixing the cairo universal build so I will then be able  
to at least try to build pango universal. I do have both a PowerPC  
and an Intel Mac in this house so my ultimate goal is to build  
graphviz universal on each machine and then run it from the other to  
make sure it works. Of course this may not test all functions of  
pango or the other libraries.