Boost logo

Boost :

Subject: Re: [boost] trunk vs release (qtsync)
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-05-24 10:37:24

Juergen Hunold wrote:
> Maybe we should do it like Qt. They use a perl script called
> "sync-qt" to build the QTDIR/include tree on demand. The "include"
> tree then contains simple header files which just #include the "real"
> headers without anything else.
> Just clone git:// and take a look at
> bin/sync-qt To see it working, just start a (shadow) build using
> "configure" and take a look at the generated include tree.
> The release packages contain this tree so end users don't need to
> have perl installed.

Thanks for pointing this out.

I'd seen all those forwarding headers as a user of Qt but never realized
they were automatically generated. I found them only mildly
distracting; your compile errors are never exactly where you expect
them, but then again not too far away.

Clearly this is a workable system for Qt, but: why, originally? AFAICT,
trolltech doesn't version their components separately; they don't
provide subdistributions of qt; it is a massive package. Maybe it is
just more convenient for them to have their headers next to their .cpps.
Was it so that they could jury-merge (q.v. 'jury rig') by copying
subdirectories around?

Conclusion: should give it a try, see what happens.

Details and walk-through

% ./configure
mkdir /tmp/qt/include
mkdir /tmp/qt/include/QtCore
header created for /tmp/qt/src/corelib/codecs/qiconvcodec_p.h (2)
header created for /tmp/qt/src/corelib/codecs/qtextcodec.h (5)
header created for /tmp/qt/src/corelib/codecs/qlatincodec_p.h (2)
mkdir /tmp/qt/include/QtDBus
mkdir /tmp/qt/include/QtDBus/private
header created for /tmp/qt/src/dbus/qdbusxmlparser_p.h (2)
header created for /tmp/qt/src/dbus/qdbusintegrator_p.h (2)

when it starts building things, only the generated include paths are

Creating qmake. Please wait...
g++ -c -o project.o -m64 -pipe -DQMAKE_OPENSOURCE_EDITION -I.
-Igenerators -Igenerators/unix -Igenerators/win32 -Igenerators/mac
-I/tmp/qt/include -I/tmp/qt/include/QtCore -I/tmp/qt/src/corelib/global
-DQT_NO_COMPRESS -I/tmp/qt/mkspecs/linux-g++-64 -DHAVE_QCONFIG_CPP

Looking at the generated include directory:

   % ls -R include | wc -l

about 5k files. A user would typically #include <QtGui/QScrollArea>,
which would include:

   % cat include/QtGui/QScrollArea
   #include "qscrollarea.h"

   % cat include/QtGui/qscrollarea.h
   #include "../../src/gui/widgets/qscrollarea.h"

   % grep class src/gui/widgets/qscrollarea.h
   class QScrollAreaPrivate;
   class Q_GUI_EXPORT QScrollArea : public QAbstractScrollArea

This is what happens in the source tree. In the distribution,
include/QtGui/qscrollarea.h contains the code for QScrollArea instead of
the forwarding include to the src directories. So one fewer forwarding

Other random observations:

* The bin/qtsync script is > 1k lines of perl.

* For the most part the list of headers to generated is globbed; there
is some kind of naming scheme for .h files that shouldn't have
forwarders generated (looks like *_p.h are excluded).

* In Qt, there are almost no headers that don't have a corresponding
.cpp file. A different style than boost.

* Perhaps one of the main advantages of this scheme is that you can
keep your .h files right next to your .cpp files in your src/ directory.
  This way when you want to change QScrollArea, everything is nearby.

* Qt was developed privately (no outside scm access) for many years.
They distributed tarballs and accepted patches in the mail. (correct me
if I'm wrong here). The announcement that direct access to SCM was
available was only a couple weeks ago.

* According to this post from a qt dev:,
end users would "usually never need" syncqt. Now that their source code
is open and anybody building from source will encounter it, I wonder if
this will become more problematic.

* Juergen tells me that this script originally used symlinks on unix and
copies on windows.


Boost list run by bdawes at, gregod at, cpdaniel at, john at