
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