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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-16 02:57:54

Felix E. Klee wrote:

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

Speaking of the first, is this a problem in practice. As I understand it,
qmake requires to declare all mocced header, too. To avoid it, one can:

1. Use "moc_h" extension for headers and then do

qt.exe hello : hello.cpp [ GLOB . : *.moc_h ] ;

However, your observation still applies: it's another way to explicitly 
specify the list of mocced files. If you add Q_OBJECT, you need to change
that list. And in this requires file renaming. (How do you do that
in CVS, for one thing?)

2. Auto-detect the list of mocced headers. But this is non-trivial. (And 
non-explicit).

About the new targets types: what's wrong with them? They'll be derived from
corresponding general types, e.g qt.exe will be derived from exe. In fact,
they would only add <qt.moc>on feature to the properties.

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

I meant, "*moc.cpp" -- not a single file! Sorry for being unclear. It's no
big difference how the file is named: "moc_hello.cpp" is possible as well
as hello.moc.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).

The problem is that while Jam can scan header files, in does so during 
deciding how to update the dependency graph. Changing the dependency graph
is likely to break almost everything.

- Volodya