Re: [Mingw-cross-env-list] Static vs. shared Qt

[Mark Brand]

Just to avoid any misunderstanding, I am a big fan of static linking for 
Windows. As far as I am personally concerned, shared linking is just a 
last resort solution for the jscore symbol conflict when linking to both 
QtWebkit and QtScript, which I don't happen to do anyway.

> I see the sentiment here, but if your application has to
> ship with a bunch of DLLs anyway (QtCore, QtGui, etc.),
> why not adding some more to save some space. :-)

Little space would be saved. Probably all the Qt DLLs contain zlib, but 
png, jpeg, tiff, and mng are only in QtGui or the respective image 
format plugins, depending on the configuration. Similarly, postgresql, 
freetds, and odbc are only in QtSql or the plugins.

The worst thing I can think of about this is that openssl is in 
QtNetwork but also with postgresql either in QtSql or the plugin.

> On the other hand, it *might* be a good idea to keep
> the number of DLLs to a minimum. For instance, creating
> one big Qt-DLL, one extra DLL for QtScript,

Actually, it's QtWebkit that has to be isolated since it has its own jscore.

I would not recommend one big Qt-DLL. The standard Qt modules are 
well-established and expected in this form by users. Also, the trend in 
the development of Qt is increased modularization. Consider that Qt 5 
modules are even split into different git repositories.

> > > Which leads us back to a recurring issue of static vs
> > > shared: Once I implemented our multi-target approach,
> > > does it make sense to apply this to static/shared, i.e.
> > > treating the "mainly-static" and "mainly-shared"
> > > approaches as two separate targets?

[..]

> The first question is how to encode this in the TARGET - as
> a second vendor, or as a suffix to "mingw32", or whatever?
>
> The second question is whether that additional TARGET is
> worth the additional maintainance overhead. For instance,
> what about win32/win64/osx all in combination with
> static/shared? That might become huge, especially if we
> need separate build rules for each of these 6 variants.
>
> Also, I wonder whether it really makes sense to build
> shared libraries via mingw-cross-env, given the already
> existing projects which seem to do the trick as well:
>
>      http://mingw-cross-env.nongnu.org/#see-also
>      
> http://download.opensuse.org/repositories/windows:/mingw:/win32/SLE_11/noarch/
>      https://admin.fedoraproject.org/pkgdb/acls/list/**mingw**
>
> That's why I'd like to head some opinions on that.

The unique thing about mingw-cross-env that I really like is that it's 
not concerned at all about packaging. This makes it very transparent, 
lightweight and easy to configure, update and experiment with. No 
package repositories, RPMs, manifests, etc to mess around with. If I 
were to start needing shared libraries, I think I would prefer a system 
like mingw-cross-env's.

Supporting shared libraries should in principle mean less work than 
static, since a lot of the work in mingw-cross-env has been fixing lists 
of sub dependencies (often with pkg-config) and this is very specific to 
static linking.

Like Tony I'm wary of complicating the elegant simplicity of 
mingw-cross-env for the sake of new targets.

But these are just my unripe musings. I'm curious about what others 
think about these questions.

Mark