[Interest] Distributing custom qt build to a group of developers

[Bo Thorsen]

Hi Adam,

I have to admit that I think you are on the completely wrong track here. 
You are using svn as a distribution channel, and that's most certainly 
not the purpose of the tool. Checking builds into svn is of course going 
to increase the size of the working copy and the repository by gigabytes 
on every release.

You have several different approaches to handle this, and I can give you 
two of them here.

You can have a build script so each developer builds a new Qt on his own 
machine. If one person updates the script on a new release (and this 
should be in svn of course), then it's not going to take any time to 
start the build on the developer machines. And they can just start a 
build when they leave in the evening.

Another approach is to have pretty much the same setup as you have now. 
But instead of putting /qtbuild in svn, you place it on an ssh server 
and distribute with rsync.

Yet another approach is for the build guy to create a zip file with a 
new /qtbuild. Then each developer can get the zip file, wipe the old 
/qtbuild and unpack the new one.

I hope this helps.

Bo Thorsen.

Fionia Software - Qt experts for hire.


Den 21-09-2012 01:03, Adam Light skrev:
> My company currently has a Subversion repository for Qt that looks 
> like this:
> /qtbuild
>   /qt
>   /build
>     /macosx
>   /install
>     /macosx
>     /win32
>     /win64
>
> The /qt directory contains a git checkout of qt.
> The /install subdirectories contain the compiled frameworks/dlls for 
> both a debug and release build of qt.
> The /build/macosx directory contains all of the object files generated 
> when compiling. These seem to be required to be able to step into qt 
> code using gdb.
>
> When a new version of Qt is released, I checkout that tag in the /qt 
> directory and then rebuild Qt using certain configuration settings. I 
> then commit all changes (the new frameworks/dlls, object files, etc.) 
> to the Subversion repository. Other developers at my company can then 
> update their Subversion checkouts so they have the new version of Qt.
>
> This works pretty well except that it requires checking a lot of 
> binary files into Subversion, and both committing the files and 
> checking them out is very slow. The size of the working copy is also 
> extremely large (this can be addressed partly by using Subversion's 
> sparse checkout feature). The repository on the server is also quite 
> large.
>
> We use this process in part because some developers use 
> not-so-powerful machines (and/or Windows virtual machines) on which 
> compiling Qt can take multiple hours. Furthermore, as long as everyone 
> runs svn update when I build a new version of Qt, we know that we are 
> all using the same version and libraries.
>
> But I wonder whether there is a better way to handle this. How do 
> other groups handle this? Using the binaries and/or SDK available for 
> download is not an option for us because we need different 
> configuration options and we sometimes need to patch Qt's source to 
> fix bugs that have not bee fixed in Qt's git repository.
>
> Thanks for any ideas.
>
> Adam
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


-- 
Bo Thorsen.
Fionia Software - Qt experts for hire.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120921/e146d2da/attachment.html>