upcoming qt4-mac changes

[Michael Dickens]

Begin forwarded message:
> From: michaelld at macports.org
> Subject: [72874] trunk/dports/_resources/port1.0/group/qt4-1.0.tcl
> Add in a few more variables; set all variables to 'global' to allow
> for use in variants and enbedded stages.

Related to this change, I've also tracked down 3 other issues with QMake:

0) I was wrong about Qt 4.7.0 messing up the install name of non-plugin libraries.  For plugins the self-id does not matter, but for libraries it does -- because some other project might link to the library, which effectively copies the self-id name as the link-to library name for the 'using' project.  So, for example, if I look at 'otool -L' for libqwt.dylib (default, non-corrected, from qwt52), I see (right now) that the self-id name is just "libqwt.5.dylib".  QMake uses the CONFIG parameter "absolute_library_soname" to generate the full-path self-id name for libraries -- this seems like a wise option to always be using, so that we're not forced to correct self-id's all over the place.  qt4 uses this option internally when building, but doesn't include it in the macx-g++ default qmake.conf file.  So, I'm going to add it with the next revision of qt4-mac for the conf files of interest (macx and darwin).

1) Sometimes QMake will generate a string like "-arch i386 -arch" without specifying the second arch (see, e.g., ports djview and liblastfm).  I believe this was fixed in the mkspec files for 4.7.0; I'll check this to make sure, and remove those particular patches if so.

2) In ports that use QMake that try to build using a locally created library which is also already installed into ${prefix}/lib, linking will currently find the already installed library no matter if the local library's path is included or not (as "-L../FOO" or whatever).  This is because Qt's libraries are installed into ${prefix}/lib, and that QMake is sloppy in the way it orders header and library paths (the same also holds true for headers).  I'm going to update qt4-mac with fixes so that these paths are inserted -after- all of those specified by the user's QMake file(s), which should help mitigate this issue for most QMake oriented projects (see, e.g., qscintilla and qwt52 -- those ports that install Qt-based plugins as well as libraries).

I'm also fixing a number of outstanding tickets w/r.t. qt4-mac, including allowing the use of ccache to help reduce compilation time.  I think I've figured out a way to allow QMake to play nicely with CCACHE (i.e., use it when specified and not when not), and I'm playing with this change right now.  I'd -love- to be able to speed up qt4 compilation!

So, sorry about the upcoming (sometime in the next few days) rev bump to qt4-mac w/o an actual Qt version bump, but it will help save us port developers some pain in either patching the issues or in figuring out what's wrong in the first place. - MLD