[Interest] packaging a build
bo at fioniasoftware.dk
Fri Sep 7 18:13:01 CEST 2012
An alternative to this is to use cmake and cpack. It's *much* easier to
do than trying to create your own package. It handles the dependencies
It's quite normal for me to deliver Windows packages to my Qt customers,
and I pretty much always end up doing a cmake build just for the delivery.
In case you haven't tried cmake before, you do have a bit of work ahead
of you there as well :) You can find an example of how to do this in the
cmake version of my fseditor:
http://www.fioniasoftware.dk/fseditor.html. This example uses NSIS to
create a full installer, but cpack can create a zip file as well.
And you probably need to read the cmake + Qt5 thread that's running
right now as well.
Good luck with it.
Den 07-09-2012 10:14, Till Oliver Knoll skrev:
> Am 06.09.2012 um 23:52 schrieb Morgan McKenzie <speedin_up at hotmail.com
> <mailto:speedin_up at hotmail.com>>:
>> ..., but on another Windows 7 64 bit computer, also with
>> 2010 re-distributable installed, it does not work.
> Sounds to me like you're in the Manifest Fiasko(tm)!
> The safest and least painful way is to create an MSI Setup (Installer)
> which - within Visual Studio Professional/Enterprise - is only a click
> on some checkbox away from "bootstrapping" for you the proper "C/C++
> runtime" at installation time and, if necessary, install it under
> c:\windows\system\WinSxS (or similar).
> The downside of that approach is you a) need Visual Studio
> "Professional" or up (or whatever it is called these days) and b) last
> time I checked no other free Installer (e.g. InnoSetup) provides this
> option to "bootstrap" for the proper C++ runtime.
> However the free MSI Installer WiX (-> google -> SourceForge) might be
> able to do that, but we're talking "XML setup files hacking" here - no
> The hardcore way is to place the necessary Visual Studio C++ runtime
> DLLs - I did not see them in your list! - manually either into the
> same place as the *.exe and mess around with the "Manifest" file. I
> can't remember the details, but I was involved in that mess once, too.
> You might find helpful information here:
> Back in those days we eventually succeeded to ship our Qt application
> (built with Visual Studio 2003, later 2005) by simply providing the
> C++ runtime libraries in the same location as the *.exe - attention:
> don't confuse debug/release versions here either! - and messing around
> with the Manifest file (again, can't remember the details).
> But in the end we still had one system - some Japanese Windows XP -
> which refused to start our application (it worked with the MSI
> Installer though)! So it turned out not to be 100% failsafe.
> With MinGW and gcc on the other hand you don't have to mess around
> with all these "Side by Side" installations etc. All you need to do is
> use Dependency Walker and provide all those DLLs, typically in the
> same directory as the *.exe.
> Qt plugins is yet another topic and has nothing to do with the
> compiler or the app not starting up (plugins are usually optional
> components, and in the worst case you simply miss some functionality -
> but the application usually starts up, unless it is some critical
> "platform abstraction plugin" or whatever)! Only there comes -
> optionally - the mentioned qt.conf file into play. Or you set the
> expected "Qt plugin base directory" programatically, e.g. relative to
> your *.exe's path. Or you simply place them where Qt looks for them
> anyway by default (e.g. /your/app/path/images - NOT ../plugins/images!
> -> chech Qt docs
> Interest mailing list
> Interest at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest