Re: [jamboost] Adding QT support to Boost Build V2

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
> that:
>
> 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
> includeded.

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?

Okay.

Thanks for your help so far.

Felix

-- 
To contact me personally don't reply but send email to 
felix DOT klee AT inka DOT de