[Qt-interest] Distributing Qt with source code using Visual Studio
Daniel Bowen
qtmailinglist1 at bowensite.com
Fri Jul 1 18:31:31 CEST 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110701/4527110a/attachment.html
More information about the Qt-interest-old
mailing list