[Qt-interest] Distributing Qt with source code usingVisual Studio
Scott Aron Bloom
Scott.Bloom at onshorecs.com
Fri Jul 1 18:39:35 CEST 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110701/f9a1eb7b/attachment.html
More information about the Qt-interest-old
mailing list