[Qt-interest] Distributing Qt with source code usingVisual Studio
Eli Hooten
elir.hooten at gmail.com
Tue Jul 5 23:05:29 CEST 2011
I know the following question is 99% Visual Studio related and perhaps 1% Qt
related, but since I've received good advice concerning Visual Studio so
far, I thought I'd post this question in this thread in the hopes that
previous posters would chime in again.
As evidenced by my earlier post, I am attempting to distribute the Qt source
along with my Qt application so that a developer with no previous build of
Qt installed on his/her machine can open my .sln file, hit compile, and be
up and running. The previous posts in this thread have been helpful, but I'm
stuck at one point in the process. Basically, I can get my Qt application to
build the Qt source and then launch the application when the user hits the
"Start Debugging" (or presses F5) button in Visual Studio 2008. However, to
get this to work, I have to modify the user's PATH environment variable by
adding:
PATH=<relative reference to Qt directory>\bin;%PATH%
*(Note that if I don't add the $(QTDIR)\bin to PATH, the program launches
but errors with the "..cannot find QtGuid4.dll.." error, which shouldn't be
that surprising since I haven't told the application where to look!)*
as an environment variable of my Qt project (i.e., right click on project ->
properties -> Configuration Properties ->Debugging ->Environment, and type
the above string). The problem with this approach is that the environment
variable is stored in the .suo file for the project, instead of with the
.vcproj itself. So, when I distribute this application, I have to distribute
my project's .suo as well. This isn't ideal for a few reasons, and I know
there has to be a better way, but I cannot seem to find it. For some reason,
with my projects that are created to use Qt, I don't have access to the
Linker -> Input option from the project's property page so I cannot specify
Additional Dependencies in that way. Are there any other recommendations?
Perhaps something I can do in the .pro file?
Thanks,
Eli
On Fri, Jul 1, 2011 at 11:39 AM, Scott Aron Bloom <Scott.Bloom at onshorecs.com
> wrote:
> We do things in a very similar fashion..****
>
> ** **
>
> Except, all third party libraries have two locations in the repository.
> The “build” area as well as the “needed to build our tool” area.****
>
> ** **
>
> This way, we can reproduce our build environment if necessary, or release a
> new compiler based build of a third party library from the build area, to
> the “needed to build” area..****
>
> ** **
>
> Also, it allows our developers not to have to checkout the whole Qt tree,
> but only the bin/header/lib area****
>
> ** **
>
> Scott****
>
> ** **
>
> ** **
>
> *From:* qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com[mailto:
> qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com] *On Behalf Of
> *Daniel Bowen
> *Sent:* Friday, July 01, 2011 9:32 AM
>
> *To:* qt-interest at qt.nokia.com
> *Subject:* Re: [Qt-interest] Distributing Qt with source code usingVisual
> Studio****
>
> ** **
>
> I don’t think it’s all that bizarre of a requirement. We do exactly that
> in our software. I think it’s actually a good practice to not depend on the
> environment of the machine at all when doing builds (or as minimal
> dependencies as possible). That way, you have more confidence that builds
> are consistent across machines they are compiled on, and its easier to setup
> a new development machine.****
>
> ** **
>
> As for how to structure the source control for doing that. Essentially,
> under trunk / Main / branch, we have a set of “project/group” level folders,
> including one for “ThirdParty”. Each one has an include, bin, lib, etc. We
> have a “code” directory where source lives. We checkin all ThirdParty
> libraries with includes, lib, etc. If there’s no source, we just checkin the
> libraries themselves as provided, but if there’s source, we checkin the
> code, and build it ourselves. For an example layout:****
>
> ** **
>
> GroupAbc****
>
> bin****
>
> Linux-arm_v5t_le****
>
> Debug****
>
> Release****
>
> Linux-x86****
>
> Debug****
>
> Release****
>
> MacOSX-x64****
>
> Debug****
>
> Release****
>
> Windows-Win32****
>
> Debug****
>
> Release****
>
> Windows-x64****
>
> Debug****
>
> Release****
>
> build****
>
> code****
>
> Project1****
>
> src****
>
> Project2****
>
> src****
>
> include****
>
> Project1****
>
> Project2****
>
> install****
>
> lib****
>
> Linux-arm_v5t_le****
>
> Debug****
>
> Release****
>
> Linux-x86****
>
> Debug****
>
> Release****
>
> MacOSX-x64****
>
> Debug****
>
> Release****
>
> Windows-Win32****
>
> Debug****
>
> Release****
>
> Windows-x64****
>
> Debug****
>
> Release****
>
> test****
>
> TestProject1****
>
> src****
>
> utest****
>
> UnitTestProject1****
>
> src****
>
> GroupDef****
>
> …****
>
> Shared****
>
> …****
>
> ThirdParty****
>
> bin****
>
> Linux-arm_v5t_le****
>
> Debug****
>
> Release****
>
> Linux-x86****
>
> Debug****
>
> Release****
>
> MacOSX-x64****
>
> Debug****
>
> Release****
>
> Windows-Win32****
>
> Debug****
>
> Release****
>
> Windows-x64****
>
> Debug****
>
> Release****
>
> build****
>
> code****
>
> Native****
>
> log4c****
>
> log4c-1.2.1
> ****
>
> openssl****
>
>
> openssl-0.9.8k****
>
>
> openssl-1.0.0d****
>
> Qt****
>
> Qt-4.6.0**
> **
>
> Qt-4.7.3**
> **
>
> Include****
>
> …****
>
> log4c****
>
> openssl****
>
> QtCore****
>
> QtNetwork****
>
> QtXml****
>
> zlib****
>
> install****
>
> lib****
>
> Linux-arm_v5t_le****
>
> Linux-x86****
>
> MacOSX-x64****
>
> Windows-Win32****
>
> Debug****
>
> …****
>
> log4c****
>
> openssl***
> *
>
> Qt****
>
> zlib****
>
> Release****
>
> …****
>
> log4c****
>
> openssl***
> *
>
> Qt****
>
> zlib****
>
> Windows-x64****
>
> Test****
>
> ** **
>
> For ThirdParty libraries, we compile those for each platform, and checkin
> the compiled libraries and symbol files (and include, etc.). For our own
> projects, we don’t checkin the build output, but have the compile output go
> to the “published” place (GroupAbc/bin/Windows-Win32/Debug for example –
> sending intermediate files to GroupAbc/obj/Windows-Win32/Debug/Project).
> Only the includes that are public / published go into
> GroupAbc/include/Project1 (if any). In the different projects, for Windows,
> there are post-build steps that copy the dependent libraries appropriately.
> For example, on Windows, an EXE project makes sure that the DLL and PDB
> files for third party things, shared things, and projects built for a
> different group are all copied to the bin directory the EXE goes in.****
>
> ** **
>
> With ThirdParty, there’s one extra level for the project for lib, so that
> different dependencies don’t have to worry about filename collisions for
> anything. There’s also one extra level for code, with the particular
> version of the 3rd party library. The bin/lib/include that are checked in
> are the current published versions.****
>
> ** **
>
> With Qt, we compile it for the different platforms, and check in the
> output, the includes, the lib, etc. We also customize qconfig.h so that you
> pick up the right platform, based on a #define (which we define in each
> platform for building)****
>
> ** **
>
> qconfig.h:****
>
> …****
>
> #if defined(_MYCOMPANY_BUILD_PLATFORM_NAME_Linux_arm_v5t_le)****
>
> # include "qconfig_Linux-arm_v5t_le.h"****
>
> #elif defined(_MYCOMPANY _BUILD_PLATFORM_NAME_Linux_x86)****
>
> # include "qconfig_Linux-x86.h"****
>
> #elif defined(_MYCOMPANY _BUILD_PLATFORM_NAME_MacOSX_x86)****
>
> # include "qconfig_MacOSX-x86.h"****
>
> #elif defined(_MYCOMPANY _BUILD_PLATFORM_NAME_Windows_x64)****
>
> # include "qconfig_Windows-x64.h"****
>
> #elif defined(_MYCOMPANY _BUILD_PLATFORM_NAME_Windows_Win32)****
>
> # include "qconfig_Windows-Win32.h"****
>
> #elif defined(_WIN64)****
>
> # include "qconfig_Windows-x64.h"****
>
> #elif defined(_WIN32)****
>
> # include "qconfig_Windows-Win32.h"****
>
> #else****
>
> # error Please define _ MYCOMPANY _BUILD_PLATFORM_NAME****
>
> #endif****
>
> ** **
>
> We then have the qconfig.h that was generated when building Qt for the
> platform renamed for the platform (like shown above). The “baseline” for
> the includes just comes from one of the compiles for one platform. Then
> after that, we just tweak qconfig.h and add the platform qconfig_platform.h
> ****
>
> ** **
>
> When building Qt, each platform has an appropriate configure that’s run
> (there’s a Build-Windows-Win32.bat, etc. so that its repeatable). For
> example, here’s our Build-Windows-Win32.bat that’s run from
> ThirdParty/code/Native/Qt:****
>
> …
> pushd ..\..\..****
>
> set SOURCECONTROL_THIRDPARTY_FULLPATH=%CD%****
>
> echo SOURCECONTROL_THIRDPARTY_FULLPATH=%SOURCECONTROL_THIRDPARTY_FULLPATH%
> ****
>
> popd****
>
> pushd (Qt version directory)****
>
> configure -debug-and-release -opensource -shared -no-fast -exceptions -stl
> -no-qt3support -qt-zlib -qt-gif -qt-libpng -qt-libmng -qt-libjpeg -no-dsp
> -vcproj -plugin-manifests -no-rtti -openssl-linked -phonon -phonon-backend
> -confirm-license -I "%SOURCECONTROL_THIRDPARTY_FULLPATH%\include" -L
> "%SOURCECONTROL_THIRDPARTY_FULLPATH%\lib\Windows-Win32\Release\openssl"
> >config.log****
>
> popd****
>
> ** **
>
> For Linux-x86, the configure looks like****
>
> make confclean > make_confclean.log 2>&1****
>
> ./configure -prefix $PWD/install/Linux-x86 -prefix-install -release
> -opensource -shared -no-fast -largefile -stl -no-qt3support -qt-gif
> -qt-libtiff -qt-libpng -qt-libmng -qt-libjpeg -nomake docs -confirm-license
> -verbose -no-cups -no-dbus -no-nas-sound -no-sm -no-mitshm -no-glib >
> config.log 2>&1****
>
> ** **
>
> ** **
>
> We take the output, and put them in the appropriate spots in the source
> control tree (using some “publish” scripts, or just doing it manually)****
>
> ** **
>
> In our projects, we can have ThirdParty/include in the include path and do
> ****
>
> #include <QtCore/QString>****
>
> ** **
>
> In our projects, the libraries paths have
> ThirdParty/lib/(Platform)/(Configuration)/Qt, and then reference the
> particular dependencies (QtCore4.lib).****
>
> ** **
>
> For Windows, what we end up with is a Visual Studio solution (currently
> Visual Studio 2008), with lots of different projects (EXE with many DLLs,
> where some DLLs don’t reference Qt). You just have to build that solution,
> and you end up with everything you need to run and debug.****
>
> ** **
>
> -Daniel****
>
> ** **
>
> ** **
>
> *From:* qt-interest-bounces+qtmailinglist1=bowensite.com at qt.nokia.com[mailto:
> qt-interest-bounces+qtmailinglist1=bowensite.com at qt.nokia.com] *On Behalf
> Of *David Ching
> *Sent:* Friday, July 01, 2011 7:34 AM
> *To:* qt-interest at qt.nokia.com
> *Subject:* Re: [Qt-interest] Distributing Qt with source code using Visual
> Studio****
>
> ** **
>
> "Eli Hooten" <elir.hooten at gmail.com> wrote...****
>
> > I have built a Qt application in Windows using Microsoft Visual Studio
> 2008. ****
>
> > My supervisor is requiring me to distribute the code in such a way that
> other****
>
> > developers can check out the code and can essentially open the solution
> file,****
>
> > click compile, and have the application build and run without any
> problems. ****
>
> > The issue is that this must be the case regardless of whether or not the
> ****
>
> > developer already has Qt installed on his/her machine. ****
>
> ** **
>
> This is a rather bizarre requirement! Anyway, if the Qt source is
> distributed with your project, why not just put the Qt headers and libs into
> a subfolder of your project, and reference that subfolder in your project’s
> properties? At that point, the Qt headers and libs are private to your
> project and are used regardless of whether Qt is installed normally or not.
> ****
>
> ** **
>
> -- David****
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110705/31fc290a/attachment.html
More information about the Qt-interest-old
mailing list