From: Felix E. Klee (felix.klee.jamboost_at_[hidden])
Date: 2003-01-15 15:14:31
On Wednesday 15 January 2003 12:35, Vladimir Prus wrote:
> > I would like to use Boost Build V2 for building QT based applications.
> You'd probably be interested to hear that one of the tests for our
> "generators" mechanism was mirrowed for QT's UI files handling :-)
I don't know what you mean by that, but it sounds good.
> > The
> > problem with QT is that it extends the C++ programming language by
> > signals and slots and a couple of other minor features. To translate this
> > code to standard C++, one has to call the so called moc (Meta Object
> > Compiler). From the QT 3 documentation:
> > The moc reads a C++ source file. If it finds one or more class
> > declarations that contain the Q_OBJECT macro, it produces another C++
> > source file which contains the meta object code for the classes that
> > contain the Q_OBJECT macro. This generated source file is either
> > #included into the class' source file or compiled and linked with the
> > class' implementation.
> The question is how we can support this... I mean user interface. I suggest
> 1. User explicitly specifies the list of headers that must be processes
> with MOC, for example
> qt.exe hello : hello.cpp hello.h ;
IMHO, this solution has two disadvantages. Firstly, the user has to change the
header file list almost each time he adds or removes a Q_OBJECT. Secondly,
you need to introduce extra target types (qt.exe, qt.lib, etc.).
> 2. The files are converted into "moc.cpp" and compiled (i.e.) not
moc.cpp isn't a good name since there might be several files in the same
directory that need to be moc'ed. qmake, the Makefile generator which is part
of QT, uses names like moc_hello.cpp.
> Is this arrangment OK? If so, it would be relatively easy to add this. (<1
> hour if I don't run in bugs :-).
>From my perspective it is OK for now, but maybe not the best solution. It
might be better if the user could simply turn on a feature to activate QT
specific processing and Jam does all the rest, eg.:
exe hello : hello.cpp : <qt>on ;
Of course, I see that it might be problematic for Jam to decide which header
files need to be moc'ed and which ones are "external" (after all one doesn't
want to moc the standard QT include files).
> I would not like to choose the #include approach because it is more
> complicated for us.
I agree. I don't like the #include approach either. It leads to longer
compilation times and, in addition, when developing projects with qmake one
doesn't use it either.
> > In addition in QT based projects one often has to deal with .ui files
> > that are created by the QT's Designer (a GUI building tool). These files
> > have to be compiled with the so called uic (User Interface Compiler).
> > From the QT 3 documentation:
> > The uic reads a user interface definition (.ui) file in XML as
> > generated by Qt Designer and creates corresponding C++ header or source
> > files. It can also generate an image file to embed raw image data in C++
> > source code.
> This should be workable too. But let's have moc done first, okay?
Thanks for your help so far.
-- To contact me personally don't reply but send email to felix DOT klee AT inka DOT de
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk