On Thu, Nov 22, 2012 at 12:44:02PM +0000, Rutledge Shawn wrote: > On 22 Nov 2012, at 1:18 PM, Sorvig Morten wrote: > > > On Nov 22, 2012, at 1:08 PM, Konstantin Tokarev <[email protected]> > > wrote: > >> > >> 22.11.2012, 16:04, "Rutledge Shawn" <[email protected]>: > >>> Yeah I know, and that's very convenient, but I've seen installers > >>> sometimes too. > >>> > >>> We could even offer a way to make it easy for application developers > >>> to make installers, in order to standardize the Qt framework > >>> installation at bit more. For example QBS could generate a target to > >>> build an installer. If it will save memory on users' systems, it > >>> seems like a good thing, right? > >> > >> There's installer of Qt which install Qt frameworks globally to the > >> system. However, sharing them between application on end-user system > >> is not a good idea, because it may result in conflicts between Qt > >> applications. > > > > I think the way to go for deployment on Mac is definitively > > self-contained app bundles where each app carries its own copy of Qt. > > This is what macdeployqt creates. Anything else is as you say just > > going to create conflicts. Self-contained bundles are also enforced by > > the app store. > > Well if our binary compatibility guarantee is true, then what conflicts > do we worry about? If an app depends on new features which were added in > a point-release, then it will not work with an older Qt, but an > application which was shipped with the older version ought to work just > as well with the newer one. On Windows and Linux we depend on that, > right?
The reality is that this guarantee often enough does not hold in practice. Vendors of "binary" Qt based application typically test their setup against one specific (often enough patched) version of Qt which is then shipped with the application. Users are not expected to switch Qt versions, except when upgrading the whole application. Insofar are rules like "we can't add symbols in patch releases" not much more then self-inflicted pain without measurable gain. > Isn't it true that duplicate copies of Qt in every application will > result in duplicate copies being loaded into RAM too? Better double memory consumption then unexpected behaviour changes. Andre' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
