Open GoogleCodeExporter opened 8 years ago
Since this is a public task on Trolltechs tracker, I assume that such a runtime
installer is on the product roadmap.
But that possibility does not stop us from planning to do one. I see the
usefulness
for some cases. But in the first place, I have a few open questions which we may
discuss, here.
- License: I can only create Qt packages of the the opensource license of Qt.
Does
that limit the target user base to opensource tools users?
- Different compilers on Windows: We need to ship versions for MinGW, VC6,
VS2003,
VS2005 and VS2008, and the end user has to pick the right one. Who has all these
compilers?
- Manifests: Since VS2005, there is a manifest mechanism, that I first need to
understand completely. Is any extra step required after replacing the Qt Dlls?
- Location of Frameworks vs. "identification names". A very flexible but also
challenging mechanism on OSX requires some extra steps if a Framework gets
relocated.
Here is what the end user has to do:
http://doc.trolltech.com/4.4/deployment-mac.html#linking-the-application-to-qt-a
s-frameworks
How can that be eased? Do we need an installation package?
These are just some questions :)
Original comment by alessandro.portale
on 17 Sep 2008 at 7:19
> Since this is a public task on Trolltechs tracker, I assume that such
> a runtime installer is on the product roadmap.
As you note from the Task Tracker, it is scheduled for "Some future release"
which is
not very promising.
> - License: I can only create Qt packages of the the opensource
> license of Qt. Does that limit the target user base to opensource
> tools users? -
Obviously. AFAI understand the Qt licensing, commercial users need to have
commercially-licensed versions of the DLLs. And why are you worrying about any
one
other than OSS users? We are OSS people doing this for OSS people, no?
> Different compilers on Windows: We need to ship
> versions for MinGW, VC6, VS2003, VS2005 and VS2008, and the end user
> has to pick the right one. Who has all these compilers? -
Correction: You need to ship versions only for MinGW, since the Windows
downloadable
EXE from Qt's website is done by MinGW only. You don't need to worry about
others.
IIRC you need a professional license to have VS integration.
> Since VS2005, there is a manifest mechanism, that I first need to
> understand completely. Is any extra step required after replacing the
> Qt Dlls? -
Since you need to worry about nothing other than MinGW, this question does not
rise.
> Location of Frameworks vs. "identification names". A very
> flexible but also challenging mechanism on OSX requires some extra
> steps if a Framework gets relocated.
Sorry I know nothing about Mac.
> Do we need an installation package?
Basically we need just an installer which simply installs the DLLs that are
provided
by Qt's downloadable EXE. Here's a shortcut: extract the DLLs from Qt's
downloadable
MinGW-based EXE. Repack it (you obviously know how since you have made
installer for
Linguist) and distribute it. The GPL requires you to provide the source for
download
which I assume you already do, ... hey it appears that you don't host a mirror
of
Qt's source tree on your Google Code. Never mind. GPL v3 (under which Qt is
available
now) section 6d allows this:
provided you maintain clear directions next to the object code saying where to
find
the Corresponding Source.
but warns you that:
Regardless of what server hosts the Corresponding Source, you remain obligated
to
ensure that it is available for as long as needed to satisfy these requirements.
So you need to provide instructions on your Google Code website on how to
obtain the
source code, and you can simply do the unpack-repack method I suggested for the
runtime installer.
Simple, what?
Original comment by jamada...@gmail.com
on 18 Sep 2008 at 2:40
Sorry for the late answer...
1) You are right. Let's concentrate on opensource users of Qt.
2) Qt opensource also supports MSVC as compiler (I believe since Qt 4.3). Not
sure how many
Qt/Windows opensource projects use MSCV instead of MinGW since then. But let's
assume it is 50/50.
3) Let's skip OSX as long as nobody shows strong interest (and offers help in
creating a
installation package with scripts).
Given 1, 2 and 3 we greatly reduced the target audience but also the technical
problems :)
I agree that simply repacking the original MinGW-based Qt Dlls into an
installer is the wisest
thing to do. The installer has to ask the end-user for the installation
directory of the app. Then
the Insatller has to compare the Qt versions and make sure that it copies only
newer versions of
Dlls. Also, it should only _replace_ Qt Dlls; If the app didn't have a
QtWebkit.dll, no QtWebkit.dll should be installes.
No start menu shortcuts or uninstallation options, but a warning text.
I will give it a try in the next weeks. And I will host it on this projects'
page as non-featured
download.
You may help doing some publicity :) If it turns out to be useful, I will
create a proper google
project for it.
Alessandro
Original comment by alessandro.portale
on 28 Sep 2008 at 12:29
Reply per points:
2) Please let us not assume anything like that. If Trolltech caters only to
MinGW,
why should we do anything else?
> The installer has to ask the end-user for the installation directory of the
app.
No no. My idea is, install it somewhere commonly accessible like C:\Program
Files\Common Files or follow the example of Java and install to a place like
C:\Program Files\Qt 4 Libraries (like C:\Program Files\Java). It should be
possible
to register the DLLs in a way that any Qt/Win app (like Qt Designer or Qt Demos
itself does, when installed from the Qt 4 installer) can access it from that
location.
And what kind of publicity? I can advertise (i.e. create a forum post) at
QtCentre.org -- what else.
Original comment by jamada...@gmail.com
on 28 Sep 2008 at 3:48
Original issue reported on code.google.com by
jamada...@gmail.com
on 16 Sep 2008 at 9:36