Begin forwarded message:
> From: michae...@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
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
