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

[Volker Grabsch]

Mark Brand schrieb:
> >
> >This is because all DLLs will contain all (statically
> >linked) helper libraries. I don't know how much of a
> >problem this is for Qt. But I guess the only "clean"
> >solution is to build everything as a shared library,
> >not just Qt.
> 
> Right. It's not a good general solution, but it does work around the
> QtScript/QtWebKit problem.
> 
> Having said that, for some "pure" Qt applications, it might actually
> be seen as an advantage to have all dependencies embedded in the Qt
> DLLs.

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. :-)

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, and one
EXE file for the application.

> >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?
> 
> I hadn't realized you were considering a static/shared choice in the
> multi-target approach.

I didn't consider it before. It was just an idea
flashing though my head. :-)

> I think the patch in question (two messages
> ago) should still in work for "mostly shared" mingw-cross-env. The
> OPENSSL_LIBS, PSQL_LIBS, and SYBASE_LIBS lists could be reduced or
> maybe even eliminated for shared builds. Also, there's at least one
> patch to link static sub-dependencies explicitly. But this stuff
> should be harmless as-is.

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.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---