Re: [boost] trunk vs release (qtsync)

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 
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
(etc)
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)
(etc)
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)
(etc)

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

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
   4894

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
step.

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:
http://lists.trolltech.com/qt4-preview-feedback/2004-12/thread00028-0.html,
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.

-t