On 22 Nov 2012, at 1:18 PM, Sorvig Morten wrote: > On Nov 22, 2012, at 1:08 PM, Konstantin Tokarev <annu...@yandex.ru> > wrote: >> >> 22.11.2012, 16:04, "Rutledge Shawn" <shawn.rutle...@digia.com>: >>> 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? Isn't it true that duplicate copies of Qt in every application will result in duplicate copies being loaded into RAM too? I think maybe the operating system could do something about this problem, e.g. using hashing to de-duplicate code blocks or some such, but I wonder if that's ever been done, or would just be a good thesis topic at this point. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
