[Interest] [OS X/MacPorts] parallel qt4 and qt5 installs

[Thiago Macieira]

On Friday 14 November 2014 21:44:51 René J.V. Bertin wrote:
> On Friday November 14 2014 11:04:29 Thiago Macieira wrote:
> >But we can't and won't. That breaks both source and binary compatibility.
> 
> Wasn't saying you should but I don't see why it would break anything ... for
> those who build the framework that way. It'd maybe be delicate to get the
> header include paths right.

#include <QtCore/qglobal.h>

when using frameworks will look for QtCore.framework/Headers/qglobal.h, which 
is a shared name between Qt 4 and Qt 5. Since you can't have the same 
directory structure contain both Qt 4 and 5 and also support compiling against 
either on the user's choice, you have to separate by having different framework 
dirs.

> >> Ok, so making sure existing binaries don't break without a complete
> >> rebuild
> >> would require a manual set-up of all the links. That sucks :) but not
> >> overly so :)
> >
> >Huh?
> 
> Existing binaries will depend on libraries ${prefix}/lib/libQtFoo.4.dylib or
> ${prefix}/Library/Frameworks/QtFoo.framework/Versions/4/QtFoo; if I don't
> want to have to rebuild all of them I'd have to replace those dependencies
> with symlinks to wherever the libraries are moved. And that's not the
> nicest of things to do :)

Oh, you meant the binaries you already have built, in your system.

For the non-frameworks build, it should not be a problem since 
libQtFoo.4.dylib and libQt5Foo.5.dylib are co-installable. The problem only 
happens for frameworks builds. Like I said, we made the choice early on not to 
make this co-installable, since most people will bundle the frameworks into 
their applications. A system-wide Qt on OS X is rare.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center