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://gitorious.org/qt/qt.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
Conclusion: should give it a try, see what happens.
Details and walk-through
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)
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
-I/tmp/qt/src/script -DQT_NO_PCRE -DQT_BUILD_QMAKE -DQT_BOOTSTRAPPED
-DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_COMPONENT -DQT_NO_STL
-DQT_NO_COMPRESS -I/tmp/qt/mkspecs/linux-g++-64 -DHAVE_QCONFIG_CPP
-DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT project.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
% cat include/QtGui/qscrollarea.h
% grep class src/gui/widgets/qscrollarea.h
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk