Adam Strzelecki wrote: > Ziller Eike wrote:
> > Can we please already now turn a cross-platform hat on, and at least think > > about options that at least do not right away block using the same for > > non-OS X? > Sure, this is just a proposition, "bundle_qt" (proposed in latter posts) > seems to match it better. > > I do not see any reason why one shouldn’t be able to turn on copying Qt > > libs next to the application binary on Windows even without any changes on > > how Qt is built there. And usage of $ORIGIN on Linux doesn’t sound like a > > too bad idea to me either. “bundle_frameworks” already disqualifies using > > the same config option on anything non-OS X. (Aside from that, what is with > > dylib builds of Qt?) > Sure I do agree, that it should work for Windows too. But Windows is out of > my scope. Anyone eager to do similar changes for Windows? I haven't been following the whole conversation, but note that Windows already has a qmake rule for invoking windeployqt, the utility that deploys an application's Qt dependencies to a directory of one's choosing. The logic is in windeployqt.prf, and the config variable is WINDEPLOYQT. It may provide the logic needed to provide this functionality on Windows. The modern Windows API (Windows Runtime) also supports Appx frameworks. There are some experiments in code review in how to use these (and a blog post by Maurice: http://blog.qt.digia.com/blog/2013/06/14/introduction-to-windows-rt-frameworks/), but no solution has been finalized. -Andrew _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
