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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
