qt4-mac update and +universal issue

[Michael Dickens]

I think qt4-mac 4.8.1 is now working as well as it can on 10.6 and 10.7:
library, framework, debug, universal, and all combinations.  Frameworks
are installed correctly into ${prefix}/Library/Frameworks with all info
files (.la, .prf, and .pc) correctly addressing those locations; ditto
for libraries into ${prefix}/lib and their related info files.  When
qt4-mac is checked in, I'll send info to this list about the compromise
I had to make to get both frameworks and libraries working.

But before I check it in, I have a related issue to sort out.  I
appreciate any suggestions / thoughts. - MLD

Sometime recently, within the past week or so, after updating 'port'
and/or the svn trunk, I can no longer build qt4-mac as +universal.  If I
insert:

ui_msg "universal_archs == '${universal_archs}'"
ui_msg "build_arch == '${build_arch}'"
ui_msg "qt_arch_types == '${qt_arch_types}'"
ui_msg "get_canonical_archs == '[get_canonical_archs]'"
ui_msg "variant_exists universal == '[variant_exists universal]'"
ui_msg "variant_isset universal == '[variant_isset universal]'"

somewhere in the top level of the qt4-mac Portfile, the results on my
system (10.6.8, 64-bit native) are:

universal_archs == 'x86_64 i386'
build_arch == 'x86_64'
qt_arch_types == 'x86_64'
get_canonical_archs == 'x86_64'
variant_exists universal == '0'
variant_isset universal == '1' (with +universal set; '0' without
+universal)

I tried adding in "universal_variant yes", but that doesn't change
anything.  I then reverted back to the latest Portfile checkin
(4.7.4r1), and it shows the same issue.  So, it looks like some
dependency is disabling +universal and/or 'port' is messing +universal
up.  If I do:

% port installed `port rdeps qt4-mac +universal | sed -e "1d"` | grep -v
universal
The following ports are currently installed:
  autoconf @2.69_0 (active)
  automake @1.12_0 (active)
  perl5 @5.12.3_1+perl5_12 (active)

All of these set:

supported_archs     noarch

so they all seem OK.  Now, if I look at a debug log (e.g., "sudo port -d
patch qt4-mac +universal"), I see:

DEBUG: perl5 5.12.3_1 exists in the ports tree
DEBUG: perl5 5.12.3_1 +perl5_12 is the latest installed
DEBUG: perl5 5.12.3_1 +perl5_12 is active
DEBUG: Merging existing variants '+perl5_12' into variants
DEBUG: new fully merged portvariants: perl5_12 +
DEBUG: Changing to port directory: /opt/MacPorts/trunk/dports/lang/perl5
DEBUG: OS darwin/10.8.0 (Mac OS X 10.6) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing
procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing
procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a
pre-existing procedure. Target override will not be provided
DEBUG: universal_variant is false, so not adding the default universal
variant
DEBUG: Executing variant perl5_12 provides perl5_12

Oddly, I see no entry (at all) for autoconf or automake.  According to
SVN < https://trac.macports.org/browser/trunk/dports/lang >, neither
perl5 or perl5.12 have been touched in many weeks to months, so I think
it's probably something else that's the issue.  But I'm at a loss as to
what it might be.  Maybe something in 'port' itself got tweaked that's
messing up +universal in perl5?  Any ideas?